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I.  IHTRODOCTION 


Bith  the  introduction  of  additional  performance  capabil¬ 
ities  in  the  Block  1C  version  cf  the  HARPOON  cruise  missile, 
the  present  HARPCON  Ship  Command-Launch  Control  Set  (HSCLCS) 
has  proven  to  be  inadequate  for  controlling  this  new  HARPCON 
missile.  Therefore,  modifications  have  been  directed  by  the 
Chief  of  Naval  Operations,  to  take  advantage  cf  these 
supolementary  features.  The  system  specifications  have  been 
set  forth  by  Naval  Sea  Systems  Command. 

Since  the  HSCLCS  must  be  redesigned  to  facilitate  the 
system  specifications,  it  is  readily  apparent  that  a  simula¬ 
tion  model  should  be  developed  to  test  the  system  specifica¬ 
tions  and,  once  determined  to  b9  a  usable  model,  to  be 

further  used  for  training  purposes.  Th9  development  of  such 

* 

a  model  allows  an  experimenter  to  play  with  the  system,  and 
investigate  potential  problem  areas,  as  well  as,  encourage 
the  process  of  innovation. 

In  designing  a  simulation  model  of  a  real  system,  the 
goal  should  be  to  conduct  testing  to  understand  the  behavior 
of  the  system  or  to  evaluate  various  strategies  cf  system 
oreration  under  consideration.  A  further  goal  should  be  for 
the  modal  to  be  used  for  training  purposes  when  it  is  not 
feasible  or  cost  effective  to  use  the  real  system.  The  art 
of  modeling  encompasses  the  ability  to  classify  the  problem, 
abstract  the  essential  features,  and  then  elaborate  on 
these,  to  produce  a  model  wher9  useful  approximation 
results.  Special  care  must  therefore  be  taken,  to  ensure 
that  the  model  is  an  accurate  and  viable  representation  of 
the  real  system.  To  meet  this  end,  certain  criteria  must  be 
met  in  support  of  the  development  of  a  proper  simulation 
model,  including: 

a.  ease  in  understanding  by  the  user. 
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b.  a  purpose  or  goal  directed  model. 

c.  ease  of  control  and  manipulation  of  the  model. 

d.  model  completeness  on  important  issues. 

e.  no  allowance  for  nonsense  answers. 

f.  ease  of  model  modification. 

Keeping  these  criteria  in  mind,  and  realizing  that  simu¬ 
lation  modeling  is  a  learning  process,  the  task  cf  model 
develccment  may  begin. 


II.  BiafCOS  SHIPB0A8D  COMM  AND-IADMCH  COHTBOL  SET  (HSCLCS) 

SPECIFICATIONS 

This  chapter  will  summarize  the  system  specif icaticcs  as 
set  forth  in  Reference  1,  and  as  developed  by  Reference  2 
and  Reference  3.  This  phase  will  present  the  existing 
svstem,  the  needs  cf  the  existing  system,  and  technical 
constraints  imposed  cn  hardware  and  software  considerat ions. 

A.  PBESE1T  HARPOON  1EAPON  SYSTEM  (HIS) 

The  HARPOON  leapcn  System  (HIS)  was  developed  to  meet 
the  needs  of  the  Navy's  anti-ship  mission.  This  system  is 
deployed  cn  fast  attack  submarines,  several  type  aircraft 
and  surface  combatants.  The  HIS's  purpose  is  to  provide 
all-weather,  over  the  horizon,  day  /night  anti-ship  capa¬ 
bility.  It  is  composed  of  the  missile  subsystem,  the  asso¬ 
ciated  launcher  subsystem  and  the  command  and  launch  control 
subsystem.  This  thesis  shall  be  primarily  concerned  with 
the  latter. 

The  HARPOON  missile  utilizes  an  in  flight  low-level 
tralectory  with  a  pop-up  feature  during  it^s  terminal  phase. 
It  has  an  active  radar  seeker  with  counter- counter  measure 
capability  to  assist  in  attacking  over  the  horizon  surface 
targets . 

In  the  ship-launched  version,  the  HARPOON  missile 
utilizes  either  third  party  or  onboard  sensor  data  for 
targeting  purposes.  Then,  since  the  missile  requires  no 
further  information  after  launch,  it  is  considered  a  "launch 
and  forget"  type  weapon. 
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Per  tie  shipboard  configuration,  the  HWS  data  processing 
and  control  functions  are  provided  by  the  HSCLCS.  The  HSCLCS 
has  three  operating  aedes:  casualty,  normal,  and  training. 
In  the  normal  aode,  the  HSCLCS  provides  the  following  major 
functions : 

-  Distribution  of  power  to  various  HWS  equipment. 

-  selection  and  application  of  missile  warmup  power. 

-  The  ability  to  conduct  various  automatic  and  manually 
initiated  tests  which  confirm  the  operability  cf  the 
HSCLCS. 

-  Selection,  transfer,  processing  and  display  of  target 
data. 

-  Coordination  of  the  selection  of  tactical  missile  mede 
and  type  of  fusing. 

-  Selection  of  the  launcher  cell  containing  the  intended 
HARECCN  missile. 

-  Initialization  of  the  selected  missile  and  the  supervi¬ 
sion  of  the  exchange  of  data  between  the  missile  and 
other  HWS  equipment. 

-  Control  of  all  missile  firing  activities. 

These  functions  are  carried  out  primarily  by  the  HABPCON 
Control  Console  (HCC)  and  the  Weapon  Control  Indicator  Panel 
(WCIP). 

The  HCC  encompasses  most  of  the  system-unique  command 
and  launch  subsystem  equipment.  This  includes  the  Data 
Processor  Computer  (DPC)  ,  a  16  bit  microcomputer,  and  a  Data 
Conversion  Unit  (DCO),  an  analog  digital  converter.  These 
twe  components  perform  data  conversion  and  processing,  and 
provide  an  interface  with  current  ship  sensors  or  external 
equipment. 

The  WCIP  provides  the  operator  with  visual  status  infor¬ 
mation  of  the  fire  control  solution.  It  further  provides 
the  operator  with  manual  input  capability. 
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The  DFtJ  executes  c.*i  assembly  language  program  to  provide 
the  following  services: 

-  Validation  of  launch  envelope  parameters. 

-  Missile  command  generation  for  implementation  of  missile 
control  parameters  including  ship's  attitude,  search 
pattern  orders,  engine  starting,  flight  termination 
range,  altimeter  setting,  and  various  selectable  flight 
trajectory  and  maneuvering  modes. 

-  Missile  testing  prior  to  launch. 

-  Pre-launch  sequencing  and  timing. 

-  Data  formatting  and  transfer  synchronization. 

The  DCO  processes  all  digital  and  analog  signal  conver¬ 
sion.  It  further  provides  interfacing  of  target  data  inputs 
for  the  Baval  Tactical  Data  System  (HTDS)  and  it  also 
provides  for  ship  motion  parameter  conversion. 

E.  CUBBEHT  DEFICIBHCIES  IH  THE  HSCLCS 

With  the  introduction  of  new  enhancements  in  th®  HABPCON 
missile,  new  command  and  control  problems  have  also  been 
introduced.  The  current  HCIP  cannot  accommodate  these  new 
capabilities.  Further,  the  operator  is  not  provided  with 
sufficient  facilities  to  direct  and  execute  a  well-planned 
HAH  POOH  attack.  These  new  capabilities  mandate  a  substan¬ 
tial  change  in  the  hardware  and/or  software  of  the  existing 
HSCLCS.  Since  current  software  is  written  in  machine 
lanauaqe,  it  is  extremely  machine  dependent.  This,  coupled 
with  the  added  difficulty  that  different  hardware  configura¬ 
tions  exist  for  subsurface,  surface  and  air  launches, 
further  compounds  the  problem  of  software  standardization. 
Beference  2  and  Reference  3  set  forth  existing  deficiencies 
in  the  current  HSCLCS.  These  include: 

-  Full  tactical  control  of  missile  variants  (the  pre¬ 
launch  selections)  are  not  available  to  the  existing 
WCIP  . 
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-  The  SC  IP  provides  inadequate  control  for  a  well 
coordinated,  multi-ship  or  multi-platform  attack  against 
a  sinqle  surface  target. 

-  The  SCI F  provides  inadequate  control  for  a  multi-missile 
( SALVO)  attack  against  a  single  surface  target. 

-  The  SCIP  does  not  incorporate  existing  intelligence 
information  (e.g.,  target  class,  course,  speed,  sector 
of  vulnerability)  into  the  engagement  planning  process. 

-  Ho  computer-aided  engaged  planning  is  implemented. 

For  engagement  planning,  the  HSCLCS  has  the  following 
deficiencies: 

-  Insufficient  information  is  displayed  at  the  wciE  to 
permit  the  operator  to  evaluate  the  quality  of  an 
engagement  plan  (e.g.,  probability  of  acquisition). 

-  Insufficient  information  is  displayed  at  the  WCIF  to 
trovide  accurate  data,  implying  risk  to  unintended 
targets  during  booster  drop,  flyout  and  target 
acquisition. 

-  The  HCIP  provides  no  display  of  planned  trajectory, 
flight  Fath  or  seeker  search  patterns. 

-  The  HSCLCS  does  not  provide  computer-added  engagement 
plan  quality  and  safety  analysis. 

-  The  iCIP  provides  no  status  information  on  available 
missiles  and  associated  launcher. 

-  Only  track  data  for  one  track  can  be  stored,  with  no 
capability  for  multi -track  retention. 

-  Ho  means  are  currently  available  to  provide  corrections 
essential  to  missile  performance  for  the  environmental 
parameters  such  as  wind,  rain  and  sea  state. 

Hith  these  deficiences,  the  training  mode  is,  at  best, 
minimal.  since  there  is  a  general  lack  of  realism,  espe¬ 
cially  in  the  graphical  representation  of  the  engagement 
oicture,  the  operator  has  little  ability  or  inclination  to 
improve  his  proficiency. 
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C.  BflS  CONSTRAINTS 


Modifications  to  the  HSCLCS  should  take  advantage  of, 
bat  net  necessarily  be  limited  to,  the  following  new  missile 
capabilities: 

-  iayccint  selection. 

-  Bange  and  bearing  (BBL)  search  pattern  expansion  direc¬ 
tion  selection. 

-  Terminal  attack  mode  selection. 

-  Maximum  range  increase. 

-  High-altitade  flycat 

-  Pre-search  sea  skim. 

Hith  these  capabilities  in  mind.  Reference  1  has  set 
forth  the  -modification  and  specification  limitations  of  each 
of  the  components  in  the  HSCLCS. 

1.  HARPOON  Control  Console  (HCC) 

The  HCC  may  be  modified  as  required  to  accommodate 
power  and  digital  interfaces  to  ths  HCIP,  and  to  provide 
integral  mounting  with  the  WCIP.  In  addition,  the  HCC  must 
meet  the  specification  requirements  of  Appendix  C. 

2.  Data  Conversion  Dnit  (DCU) 

The  DCO  modifications  are  limited  to  the  removal  of 
circuit  cards  in  order  to  provide  required  functions  for  the 
HCIP.  It  will  provide  an  interface  with  the  ship's  motion 
systems,  target  detection  systems  ar.d  missile  launch 
equipment. 

3 •  Data  Processor  Computer  (DPC) 

The  DPC  is  a  general  purpose  computer  with  ultra¬ 
violet  erasable  programmable  read-only  memory  (OV-EPBOM) . 
This  computer  provides  weapon  control  solutions  to  the 
missile  and  provides  direct  real  time  control  of  the  HCIP. 
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It  alsc  conducts  interlock  computations  to  prevent  launch 
when  the  ship  roll  and  pitch  are  excessive,  launcher 
painting  and  stabilization  orders  and  conducts  self-tesring 
cn  the  WCIP  or  HARP0C8  missile  when  directed.  The  modified 
CPC  shall  consist  of  (a)  a  new  central  Processing  Unit 
(CPU)  ,  which  will  provide  the  computational  speed  required 
of  the  WCIP  engagement  planning  functions,  (b)  a  minimum  of 
110,000  sixteen-bit  words  of  OV-EPROH,  16,000  sixteen-bit 
words  of  random  access  memory  (BAB)  ,  and  2,000  sixteen-bit 
electronically  erasable  programmable  read-only  memory,  and 
(c)  an  BS  222  serial  interface  for  use  with  external  devices 
providing  training  or  data  extract  functions.  The  DPC  may 
be  further  modified  tc  support  the  engagement  planning  func¬ 
tions  as  specified  in  Appendix  C. 

4.  Beacons  Control -Indicator  Panel  ( WCIP)  Graphic 

Disc  lay  System 

The  WCIP  Graphics  Display  System  (GDS)  shall  consist 
of  a  plasma  graphic  display  with  embedded  microprocessor  and 
twenty  manual  entry  buttons  under  software  control.  This 
function  will  allow  the  operator  to  plan,  evaluate  and 
execute  a  HARPOON  engagement  and  to  conduct  training.  The 
disolay  is  to  provide  the  operator  with  a  visual  depiction 
of  the  tactical  engagement  situation  and  concurrent  readouts 
of  necessary  engagement  data.  It  is  noted  that  a  prototype 
disolay  has  already  been  developed,  and  is  currently  under 
evaluation. 

5.  Weapon  c cntrc  1-Indicator  Pans  1 

The  WCIP  will  be  required  to  provide  all  the  func¬ 
tions  of  the  specifications  listed  in  Appendix  C.  It  must 
provide  operator/HSCICS  interactive  functions  required  for 
engagement  planning.  It  will  provide  visual  status  informa¬ 
tion  cn  the  HARPOON  missile  and  launcher,  and  the  manual 
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controls  for  selecting  missile  initialization  functions/ 
parameters  and  firing  of  all  HARPOON  missile  variants. 
Although  target  data  entry  for  aissile  initialization  is 
normally  automatic  through  the  DCO,  alternate  manual  entry 
must  he  provided  for  from  the  WCIP. 

D.  PROPOSED  SOFTWARE  PLAN 

Reference  2  and  Reference  3  set  forth  consecutive 
refinements  to  a  software  plan.  A  requirements  analysis  was 
conducted  tc  provide  a  foundation  for  the  flow  and  structure 
cf  information  and  to  identify  interface  details  within 
existing  design  constraints.  To  accomplish  this  analysis 
the  use  of  a  data  flow  diagram  (DFD)  was  used.  This  type  of 
diagram  is  a  graphical  aid  for  demonstrating  data  flow 
during  the  designing  cf  a  software  system.  A  general  outline 
of  a  DFD  consists  of  the  following: 

1.  DFD  Attributes 

-  Information  flow  can  be  represented  by  a  DFD  for  any 
system. 

-  Each  transformation  in  a  DPD  may  require  refinement 
to  realize  a  complete  understanding  cf  the 
transformation. 

-  Data  flow  must  be  emphasized  without  regard  to 
control  of  data. 

2  •  DFE  Symbols 

-  Information  flew  is  identified  by  a  labeled  line  from 
the  source  to  the  sink  with  an  arrowhead  pointing  in 
the  direction  of  flow. 

-  Data  transformation  is  represented  by  a  circle. 

-  Information  sources  and  sinks  are  displayed  as 
rectangles. 

-  Stored  information  (i.e.,  data  bases  and  files)  are 
represented  by  two  parallel  lines. 
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3 •  DFC  Osage  Guidelines 

-  The  first  layer  of  the  CFD  is  the  system  module. 

-  The  second  layer  of  the  DFD  is  a  generalized  overview 
of  the  DFD. 

-  All  items  in  the  DFD  including  arrows  must  be 
labeled. 

-  Information  continuity  is  required  for  all  DFD 
refinements. 

-  Befine  only  one  item  at  a  time. 

-  When  uncertainty  exists  as  to  whether  further  refine¬ 
ment,  assume  that  the  possibility  exists. 

-  Fellow  data  flow  from  left  to  right. 

-  A  transformation  nay  output  control  data  for  a  subor¬ 
dinate  modula.  This  control  data  does  not  represent 
control  structure  and  therefore,  is  not  control  flow. 

Figures  2.  1  through  2.4  represent  a  refined  development 
of  the  HSCICS  by  the  data  flow  method. 
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GRAPHICS 

DISPLAY 


III.  HODILIHG  SHOCKS 


In  creating  a  siaulation  model  of  the  HSCLCS,  the 
assumption  is  made  that  the  simulation  will  be  used  to 
examine  the  properties  of  the  HSCLCS,  and,  if  found  depen¬ 
dable,  used  as  a  training  device.  In  developing  this  model, 
a  number  cf  intermediate  steps  may  be  identified  to  assist 
in  the  model  development.  Several  of  these  steps  will  be 
developed  here,  but  others  must  wait  until  actual  model 
implementation  conducted  under  other  theses. 

A.  SISTIH  DEPIIITIOH 

It  this  step  of  the  modeling  process,  a  determination 
must  be  made  of  the  boundaries  (i.a.,  what  will  be  simu¬ 
lated)  utilized  in  developing  the  system.  since  a  formula¬ 
tion  of  the  simulation  modal  may  change  as  it  is  being 
developed,  the  conditions  set  forth  at  this  step  cannot  be 
considered  solid.  Is  new  information  becomes  available, 
these  conditions  must  be  amenable  to  change. 

1 .  Boundaries 

The  HSCLCS  is  a  major  component  of  the  HIHPCON 
Heaocn  System  (HAS)  comprised  of  two  elements:  the  HIBPCOH 
Control  Console  (HCC) ,  and  the  Weapon  Control  -  Indicator 
Panel  (WCIP).  It's  primary  purpose  is  to  provide  the  capa¬ 
bility  to  initialize  and  launch  existing  H1BPOON  missiles. 
In  it*s  present  configuration,  the  HSCLCS  provides  a  weapon 
control  solution,  missile  initialization,  launcher  control 
and  missile  firing  functions.  With  new  modifications,  the 
HSCLCS  should  also  provide  engagement  planning  and  data/ 
training  extract  capability. 
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The  ICC  performs  most  of  the  data  processing  and 
conversion  necessary  for  missile  launch.  The  WCIP  provides 
visual  information  to  the  operator  during  the  fire  control 
solution  formulation,  and  further  provides  for  manual 
control  fcy  the  operator.  In  the  simulation  model  develop¬ 
ment,  it  would  appear  that  the  HSCLCS  would  be  the  sole 
cblect  of  simulation.  however,  since  the  HSCLCS  obtains 
informa  tion/da  t  a  from  other  ship  sensors  cr  from  proposed  or 
current  manual  input,  the  model  muso  allow  for  input  of 
simulated  ship  sensor  information/data  either  manually  or 
automatically. 

2.  Model  Formulation 

The  next  task  is  that  of  model  formulation:  reduc¬ 
tion  of  the  real  system  to  some  logical  flow  pattern.  The 
model  formulation  should  neither  oversimplify  the  system  nor 
overspecify  it  so  as  to  appear  awkward  or  become  exrremely 
expensive.  The  latter  case  is  usually  the  problem  area.  In 
this  simulation,  the  model  may  be  necessarily  bulky  due  to 
the  need  to  simulate  the  entire  HSCLCS  subsystem. 

In  setting  fcrth  the  model  formulation,  certain 
criteria  must  be  incorporated  to  ensure  a  good  simulation. 
Because  the  final  result  of  tb:s  simulation  is  to  be  more 
alonq  the  line  of  a  prototype  development  that  as  an  anal¬ 
ysis  tool,  the  initial  structure  for  the  model  formulation 
as  set  forth  in  the  data  flew  diagrams  of  Chapter  2  can  be 
used.  It  would  then  appear  that  each  of  the  boxes  in  the 
data  flow  diagrams  can  be  developed  into  a  module  for  the 
simulation.  Several  criteria  are  met  for  a  good  simulation 
by  proceeding  in  this  manner. 

The  first  criteria  is  that  the  model  becomes  easily 
purposa  or  goal  directed.  Each  module  will  be  developed  to 
carry  out  a  specific  task.  If  the  desired  goal  of  the  model 
changes,  such  as  for  training,  then  a  minimum  number  of 
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chanaes  will  be  required.  This  coincides  with  the  important 
criteria  of  model  ecdific aticn.  Through  the  creation  of 
modules  from  the  data  flow  diagrams,  using  the  transaction 
transform  analysis  methodology  described  in  Reference  4,  the 
effects  of  any  changes  to  either  the  design  specifications 
cr  to  the  system  design  will  be  minimized. 

Modular izat ion  can  also  lead  to  ease  of  control  and 
aanioulaticn  of  the  model.  If  the  modules  are  developed 
correctly,  that  is,  through  proper  abstraction  and  good 
interfaces,  then  the  designer  will  only  need  to  know  what 
the  module  does  and  not  necessarily  how  it  doss  it.  This  in 


turn  leads  to  a  better  understanding  of  the  system  by 
reducing  the  complexity  at  each  level  of  the  model.  This 
will- further  allow  ease  in  determining  completeness  on  all 
important  areas  of  the  model. 

Other  criteria  for  a  good  simulation  must  be 
completed  at  the  implementation  stage  of  model  development. 
These  include  ease  in  understanding  by  the  user  and  no 

allowance  for  nonsense  answers.  The  former  will  require 

carefully  designed  interaction  with  the  user,  whereas  the 
latter  will  require  input  parameter  checking. 

In  a  general  overview,  the  model  can  probably  best 
be  split  intc  4  modules:  a)  data  processing  unit(DFD),  b) 
data  conversion  unit (DCU),  c)  weapons  control- 

indicator  <HCIP)  panel  graphics  processor  and  d)  weapon 
control-indicator  panel  controls.  The  main  desire  is  to 
check  the  use  of  the  RCIP  graphics  processor  and  controls, 
however,  since  much  c£  the  input  is  through  the  DPC  and  DCU, 

they  too  will  have  to  be  simulated.  The  DPD  and  DCU  may 

carrv  the  added  burden  of  simulating  the  ship  sensors,  or 
may  sclely  provide  fata  in  a  refined  form.  The  graphics 
processor  will  probably  be  the  most  difficult  to  simulate, 
and  may  not  in  fact  be  completely  necessary.  However,  to 
ensure  some  sense  of  reality,  the  graphics  module  should 
closely  model  an  actual  display. 


Since  a  first  design  refinement  of  the  system  has 
already  keen  made,  Bef.  3  there  appears  to  be  no  real  need 
to  make  major  changes  at  this  point.  Now  the  task  of 
defining  the  structures  for  the  data  bases  identified  in 
Appendix  D ,  and  the  acdules  identified  in  Appendix  E,  can  be 
made . 

3.  Databases 

All  of  the  data  bases  in  Appendix  D  appear  to  be 
sufficient  for  the  simulation.  This  assumption  does  not, 
however,  prevent  changes  in  later  stages  of  the  model  devel- 
ooment.  If  an  element  in  the  data  base  requires  a  default  or 
initial  value,  it  will  be  accomplished  by  one  of  the  modules 
listed  in  Appendix  E. 

a.  Environmental  Data  Base 

The  Environmental  Data  Base  is  used  to  store 
informaxicm  about  current  weather  conditions,  to  be  used  in 
obtaining  a  practical  engagement  solution.  This  data  base 
will  always  reside  in  main  memory.  It  will  consist  of  a 
single  record  with  eight  fields: 

Visibility  :  integer  range  0.. 30 (miles 

Sea  State  :  integer  range  0..10 

Wind  Direction  :  integer  range  0. .  359  (degrees 

Wind  Speed  :  integer  range  0..  100  (knots 

Relative  Humidity  :  integer  range  0. .  100  (percent 

Temperature  :  integer  range  -100. . 150 (degrees  F 

Barometric  Pressure  :  integer  range  900 .. 1 100 ( millibars 

Precipitation  :  string(yes,no 

The  following  default  values  will  be  made  auto¬ 
matically  prior  to  any  manual  entry  from  the  operator,  or 
automatic  entry  from  selected  ship  sensors. 

Visibility  :  1 

Sea  State  :  1 

Wind  Direction  :  000 


Hind  Speed 

:  0 

Temperature 

:  50 

Barometric 

:  10  20 

Precipitation 

:  No 

After  initialization,  the  operator  may  input  the 
current  environmental  conditions  manually  or  allow  automatic 
updates  from  own  ship  sensors. 

t.  Launcher  and  Hissile  Status  Data  Base 


This  data  bas9  will  consist  of  an  array  of 
records  equal  tc  tie  number  of  cannisters  available  for 
launching  missiles.  It  will  always  reside  in  main  memory. 
Each  record  will  consist  of  the  following  four  fields. 
Launcher  Humber  :  integer  range  1 . . tlaunchers 

Cannister  Humber  :  integer  range  1..8 

Hissile  Type  :  integer  range  1..7 

Launch  Inhibit  :  integer  range  0..1 

The  following  values  will  be  assigned  upon  acti¬ 
vation  of  the  system.  The  values  will  be  selected  from  a 
file  in  secondary  storage.  The  file  in  secondary  storage 
may  be  modified  to  accommodate  any  type  of  platform  and  any 
type  of  missile  loadout.  When  any  changes  are  made  by  the 
o  erator  to  the  data  base,  they  may  only  be  accomplished 
using  a  special  code. 

Launcher  Number  :  current  launcher  number 

Cannister  Number  :  current  cannister  number 
Hissile  Type  :  type  missile  in  current  cannister 

(a  value  of  7  indicates  the 
launcher  is  empty  and  requires 
launch  to  be  inhibited  for  that 
cannister) 

Launch  Inhibit  :  0  (inhibited) 
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The  size  of  the  structure  holding  this  data  base 
in  main  memory  oust  be  variable  to  allow  for  the  require- 
aents  of  different  platforms.  One  method  to  permit  this 
would  be  to  have  tfce  first  item  read  from  the  secondary 
storage  file  indicate  the  size  of  the  array  (i.e.,  the 
number  of  available  cannisters)  .  If  for  some  reason  the 
size  needs  to  be  changed,  such  as  for  an  inoperable 
launcher,  the  operator  will  have  the  capability  of  changing 
the  size. 

c.  Menu/State  Data  Base 

This  data  base  will  reside  permanently  in  main 
memory.  Immediately  upon  power  up,  this  data  base  will  be 
initialized.  The  Control  Module  will  make  a  call  to  the 
Menu/State  Display  Module,  notifying  it  that  the  current 
state,  cr  process  instance,  is  0.  This  will  cause  the 
Menu/State  Display  Module  to  initialize  the  data  base  and 
enter  state  1.  The  data  base  will  consist  of  an  array  of 
records.  Several  of  the  fields  will  be  of  variable  length. 
The  fields  will  be  arranged  in  the  following  manner: 

State  :  integer  range  1..maxstate 

Number  Cptions  :  integer  1. .  maxcptions 

Menu  Display  :  array  (2, Number  Options) 

option 

Display  Location 

After  the  data  base  has  been  initialized,  the 
first  menu  that  will  be  displayed  will  be  the  main  menu. 
Thereafter,  whenever  a  menu  selection  is  made,  the  state 
will  be  identified  and  sent  to  the  Menu/State  Display 

Module. 


<3 .  Ship  Parameter  Data  Base 


Course 

Speed 


The  Ship  Parameter  Data  Base  will  consist  of 
information  about  the  operators  own  ship.  It  will  contain  a 
sinqle  record  with  four  elements,  and  will  reside  in  main 
memory. 

i  integer  range  0..359 
:  integer  range  0..maxspeed 

(maxspeed  is  maximum  speed  of  the 
platform  which  must  be  tailored 
for  each  individual  platform). 

:  record 

degrees 
minutes 
seconds 
:  record 

degrees 


Latitude 


Longitude 


integer  range  -90.. 90 
integer  range  0..60 
integer  range  0..60 


All 


minutes 

seconds 

elements  will  be 


:  integer  range 

-180..  180 

:  integer  range  0..60 
:  integer  range  0..60 
initialized  to  0  after 


which  the  operator  may  input  changes  manually.  automatic 
changes  may  also  be  made  via  ship  sensors  (e.  g. ,  pit  sword, 
dummy  log,  gyro,  navigation  equipment). 


e.  Threat  Data  Base 


This  data  will  always  reside  in  some  secondary 
snoraqe  since  it  will  only  be  needed  when  requested.  The 
potential  for  this  data  base  becoming  very  large  is  readily 
apparent.  This  data  base  may  only  be  changed  with  special 
permission.  For  the  purpose  of  this  simulation  it  will 
consist  of  a  file  of  records  with  six  elements. 

Ship  Name  :  string 

Nationality  :  string 

Ship  Class  :  string 


Neapons  :  string 

ECU  Equipment  :  string 

Engagement  Method  :  string 

All  information  in  this  data  base  may  be  changed 
by  the  operator  using  a  special  code.  The  information  in 
this  file  »ay  be  of  classified  origin.  The  data  base  should 
have  the  capability  of  being  accessed  for  specific  informa¬ 
tion  by  tke  Ship  Ease.  Further,  to  facilitate  flexibility,  a 
list  of  ships  should  be  capable  of  being  accessed  by  using 
the  Nationality  or  Ship  Class  elements. 

f.  Engagement  Data  Base 

This  data  base  will  be  utilized  in  conjunction 
with  the  Track  Data  Ease.  Since  there  will  be  a  need  for 

information  in  both  data  bases  to  be  identified  by  a  track 

number,  it  appears  appropriate  to  store  both  data  bases  as 
one.  However,  each  data  base's  manager  will  only  have 
access  to  a  portion  of  the  information.  To  allow  for 
engagement  of  up  to  20  tracks,  an  array  of  20  elements  will 
be  needed.  Each  of  the  array  elements  will  consist  of  a 
record  with  sixteen  fields. 

Track  Number  :  integer  range  100.. 3199 

Type  Track  :  integer  range  1..7 

(1=Surface  Friendly) 

(2=Air  Friendly) 

(3=Subsurface  Friendly) 
(4=surface  Hostile) 

(5*Air  Hostile) 

(6*Subsurf ace  Hostile) 

(7*Unknown) 

Type  Engagement  :  integer  range  0..1 

(0*Hanual  ,1  =  Auto) 

Class  of  Vessel  :  integer  0..1 

(0=Large,  1=Small) 

Bearing  :  integer  range  0.359 (degrees 
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Hange 

Latitude 


Longitude 


Course 

Speed 

Number  Hiss  Fire 
Firing  Sequence 
Tvpe  Hissil9 
Flight  Path 
Ba YFoints 
Missile  Selected 


:  integer  range 
:  record 

Degrees  : 

Minutes  : 

Seconds  : 

:  record 

Degrees  : 

Minutes  : 

Seconds  : 

:  integer  range 
:  integer  range 
:  integer  range 
:  array  range  0. 
:  integer  range 
:  TBD 

:  TBD 

:  integer  range 


0. . maxrange (miles 

integer  range 
-90. .90 

integer  range  0..60 
integer  range  0..60 

integer  range 

-180. . 180 

integer  range  0..60 
integer  range  0..60 
0 . . 359  (degrees 
0 . .  max  (knots 
0..8 
.max 
1.  .4 


1. .  max 


4 .  level  _1  Modules 


Level  1  is  the  highest  level  i.i  the  simulation.  It 
corresponds  to  the  Control  Module  of  Figure  2.1.  It  is  this 
module  which  will  be  responsible  for  controlling  all  lower 
level  modules  and  ensuring  that  zhe  simulation  always 
remains  in  a  consistent  state.  Immediately  upon  activation 
of  the  system*  the  Control  Module  will  be  responsible  for 
initializing  all  of  the  data  bases  with  their  required 
default  values.  This  may  require  the  addition  of  a  module 
to  perform  initialization  and  to  input  default  values  as  the 
coerator  makes  additions*  deletions  and  changes  to  appro¬ 
priate  data  bases. 


The  Control  Module  will  also  be  responsible  for 
ensurinq  that  sufficient  parameters  are  available  when 
calling  lower  level  procedures.  It  will  be  at  this  level 
that  lower  level  modules  requiring  a  "time”  field  for  their 
data  structures  will  obtain  the  correct  time.  This  need  for 
a  "time"  field  will  be  addressed  in  the  next  chapter. 

The  simulation  must  further  meet  the  specifications 
cf  Appendix  1,  reguiring  a  training  mode  and  data  extract 
capability.  These  features  should  be  incorporated  to  allow 
the  user  tc  specify  a  training  or  a  full  simulation  mode.  If 
the  training  mode  is  selected  than  a  file  in  secondary 
storage  will  be  opened.  Whenever  any  change  is  made  in  any 
data  base,  the  change  will  be  entered  sequentially,  with  the 
time  of  tie  change  in  the  secondary  storage  file.  This  will 
allow  for  later  retrieval  of  the  data  so  the  operator  may 
study  and  evaluate  his  training  session. 

5 .  Level  2  Modules 

There  are  twc  modules  at  this  level:  the  Process 

Module  and  the  Display  Module.  Normally  the 

Launcher/Missile  Assignment  Module  would  be  at  this  level, 
however,  it  has  been  moved  to  level  3  to  allow  for  manual 
input  of  launcher  and  missile  assignment.  This  will  permit 
the  operator  to  fire  a  missile  quickly  should  the  tactical 
situation  dictate,  without  having  the  engagement  analyzed. 
This  does  net  prevent  automatic  engagement  which  may  also  be 
dependent  upon  time  constraints  and/or  the  tactical 
situation. 

a.  Process  Module 

The  Process  Module  will  control  the  selection  of 
lower  level  modules  for  addition,  deletion  and  making 
changes  in  appropriate  data  base  records.  The  only  informa¬ 
tion  which  the  Process  Module  should  return  to  the  Control 
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Module  is  information  concerning  errors  in  improper  param¬ 
eter  passing  and  records  not  found  error  messages.  If  the 
operator  selected  the  training  mode  at  the  Control  Module 
level,  the  Process  Module  should  have  been  passed  this 
information  just  one  time.  This  will  allow  all  changes, 
additions  and  deletions  to  be  written  to  a  secondary  storage 
file.  Further,  if  the  information  is  passed  just  once,  then 
valuable  time  will  not  be  wasted  at  each  call  to  the  Process 
Module  to  see  which  simulation  mode  has  been  selected.  The 
Process  Module  should  also  prevent  unauthorized  changes  in 
the  Threat  Data  Base  Manager  Module.  The  latter  requirement 
may  not  be  needed,  as  will  be  addressed  later.  The  Process 
Module  will  carry  the  added  burden  of  simulating  ship 
sensors,  NTDS  and  third  party  information.  These  tasks 
should,  if  possible,  be  conducted  concurrently. 

b.  Display  Module 

Here  is  the  module  that  has  the  potential  to 
become  very  large.  The  Display  module  must  display  all 
requested  information  without  destroying  any  data  in  any  of 
the  data  bases.  This  module  should  only  pass  information  to 
the  control  module  concerning  errors  in  requests  for 
displays  that  do  not  exist.  This  module  will  undoubtedly 
require  additional  refinement  when  the  model  progresses  to 
the  model  enters  the  testing  phase  of  the  model  simulation. 

6 .  Level  3  Modules 

Most  of  the  data  base  managers  occur  at  this  level, 
with  the  exception  of  the  Plan  Engagement  Data  Base  Manager. 
The  majority  of  the  graphics  display  modules  are  also  at 
this  level.  It  is  here  that  extreme  care  must  be  made  in 
granting  write  access  to  the  data  bases  and  ensuring  that 
chanqes  to  fields  in  the  data  bases  are  within  appropriate 
ranaes.  This  might  be  accomplished  as  an  input  control. 


a.  Ship  Parameter  Data  Base  Manager 


This  is  the  only  nodule  which  will  have  write 
access  to  the  Ship  Parameter  Data  Base.  After  initializa¬ 
tion  of  the  data  base,  the  operator  will  be  able  to  change 
the  fields  manually.  Automatic  updates  may  be  made  through 
the  Control  Module  frcn  own  ship  sensors  (e.g.,  gyro,  navi¬ 
gation  equipment)  .  The  Control  Module  will  ensure  that 
undated  information  is  passed  to  this  module  as  required, 
and  upon  every  speed  or  course  change.  During  the  period 

between  updates  ordered  by  the  Control  Module,  the  Ship 
Parameter  Data  Base  Manager  will  cause  updates  every  minute 
based  upon  current  course,  speed  and  position  in  the  data 
base.  This  will  permit  those  modules  with  read  access  to 
the  data  base  to  have  reasonable  confidence  in  the  accuracy 
of  the  data.  If  the  Control  Module  was  unable  to  obtain  an 
uodate  from  own  ship  sensors,  the  operator  will  be  notified 
that  the  data  may  be  out  of  time  tolerance.  This  might  be 
accomplished  by  prompting  the  operator  for  input  at  the 
required  time,  and  notifying  him  what  equipment  has  failed. 

b.  Environmental  Data  Base  Manaqer 

This  module  is  responsible  for  updatinq  the 
Environmental  Data  Base.  It  is  the  only  module  with  write 
capability  to  this  data  base,  since  most  of  the  data  in  the 
Environmental  Data  Ease  will  remain  accurate  for  several 
hours,  with  the  exception  of  wind  speed  and  direction,  there 
is  no  mandatory  updates  unless  specified  by  the  operator. 
In  the  case  of  mandatory  updates,  the  operator  nay  specify 
tine  intervals  in  the  Control  Module,  to  permit  checking  of 
ship  sensors  for  wind  speed  and  direction  only. 
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c.  Convert  coordinates  Module 

This  nodule  will  provide  a  capability  for  the 
Track  Data  Base  to  be  updated  either  manually,  from  own  ship 
sensors,  or  via  the  NTDS  link.  As  this  module  receives 
infornaticn,  it  will  deter nine  the  coordinate  system  repre¬ 
sented  by  the  data.  The  Convert  Coordinates  Module  will 
then  change,  if  necessary,  this  data  to  coordinates  in  the 
reference  systen  the  operator  has  selected  (i.e. ,  true,  NTDS 
grid,  geographic).  If  this  nodule  has  been  accessed  solely 
to  add  or  delete  information,  then  no  conversion  should  take 
place.  It  any  point,  if  the  operator  chooses  to  change  the 
reference  systen,  this  nodule  will  nake  the  appropriata 
conversion  cf  data  for  the  display. 

d.  Threat  Data  Base  Manager 

The  Threat  Data  Base  Manager  will  be  used  to 
change  data  in  the  Threat  Data  Base.  It  is  the  only  module 
that  will  have  write  access  to  this  data  base.  If  a  change 
is  made  to  this  data  base,  it  should  be  done  prior  to 
connencinq  training  or  at  tines  when  the  system  is  solely 
activated  for  this  purpose.  The  najor  reason  for  this  is 
the  potentially  large  size  requires  than  it  be  stored  in 
secondary  storage,  thus  significant  time  will  be  required  to 
access  the  desired  data  to  nake  changas.  For  the  purposes 
of  this  simulation,  this  model  can  most  probably  be  deleted. 
The  reason  for  this  is  that  since  only  twenty  keys  are 
required  to  be  under  software  control,  the  real  system  will 
probably  be  updated  off  line.  This  should  not  detract  from 
the  overall  testing  cf  the  system  in  later  phases.  It  is 
anticipated  that  secondary  storage  will  be  either  a  hard 
disc  or  bubble  memory. 
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e.  Menu  Display  nodule 


This  module  will  select  the  appropriate  menu 
from  the  Menu/State  Data  Base  and  display  it  on  the  screen. 
The  Benu  Display  Hodule  will  always  keep  track  of  the 
current  state  of  the  system,  and  only  display  the  available 
alternatives.  Ho  alternatives  should  be  made  available  that 
can  not  be  carried  cut  (e.g.,  allowing  a  change  to  the 
Environmental  Data  Base  when  the  Ship  Parameter  Data  Base  is 
currently  accessed)  .  411  menus  should  have  the  capability 

of  escaping  to  the  Bain  menu.  This  feature  will  always 
allow  the  operator  to  escape  in  order  to  fire  a  missile. 
Since  this  allows  the  operator  to  escape  before  all  neces¬ 
sary  data  might  be  input,  there  will  be  times  when  changes 
to  data  bases  should  not  be  made  until  all  the  required 
information  has  been  entered.  An  example  is  adding  a  track 
and  assigning  a  missile  without  providing  some  information 
concerning  range  and/cr  bearing.  In  this  case,  no  track 
should  be  addad  until  minimal  information  has  been  provided. 
The  only  information  that  must  be  passed  to  this  module  is 
the  current  state.  Since  the  specifications  only  call  for 
20  keys  tc  be  under  software  control,  many  of  the  keys  will 
be  reguired  to  have  multiple  menu  assignments.  The  key  will 
therefore  have  to  be  displayed  with  the  menu  selection  to 
which  it  pertains. 

f.  launcher  Hissile  Status  Display  Hodule 

Here  the  operator  is  provided  with  the  ability 
to  check  the  current  missile/launcher  status  for  the  entire 
system,  or  any  portion  thereof.  Tha  Launcher  Hissile  status 
Data  Base  may  be  read  by  this  module,  but  may  not  make  any 
changes  to  it.  If  the  operator  desires,  he  may  select 
display  for  a  particular  missile,  all  missiles  in  a  specific 
launcher,  or  for  the  status  of  all  missiles. 


g.  Environmental  Display  Module 


When  called  by  the  Display  Module,  the  current 
values  for  the  environmental  conditions  from  the 
Environmental  Data  Base  will  be  displayed.  This  module  will 
only  have  read  capabilities  on  the  data  base.  However,  the 
ooerator  will  be  able  to  select  from  one  of  the  menus  to 
make  a  change. 

h.  Engagement  Display  Module 

The  Engagement  Display  Module  controls  several 
lover  level  modules.  It's  main  purpose  is  to  decide  which 
nodule  to  select  based  upon  the  operators  desires.  It  will 
cause  information  from  the  Threat  Data  Base  to  be  displayed, 
cr  information  about  the  current  engagement  plan.  If  the 
ooerator  selected  the  manual  engagement  display,  he  will 
have  the  opportunity  to  input  his  own  engagement  plan  and 
see  what  will  happen,  prior  to  any  changes  being  entered  in 
the  data  base.  This  will  present  the  operator  an  opportu¬ 
nity  to  check  his  plan  before  instituting  it. 

i.  Ship  Parameter  Display  Module 

This  module  will  display  all  information 
currently  in  the  Ship  Parameter  Data  Base.  It  will  only  be 
able  tc  read  from  the  data  base,  aud  present  the  information 
in  an  intelligible  fcrs  for  the  operator  to  understand.  k 
menu  selection  will  be  available  when  this  module  is  called, 
to  oermit  the  operator  to  institute  a  change  to  the  data 
base. 

1.  Track  Display  Module 

This  is  the  last  module  at  level  3.  It's 

purpose  is  to  display  all  tracks  currently  in  the  Track  Data 
Base.  k ry  time  any  change  is  made  in  the  Track  Data  Base, 
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the  display  should  reflect  the  change.  This  information 
should  be  displayed  at  all  *  times  for  the  operator.  To 
facilitate  this,  all  menu  displays  and  other  information 
must  be  displayed  on  areas  of  the  screen  outside  the  track 
disolay.  The  one  exception  to  this  is  the  engagement 
display  which  must  be  superimposed  on  the  track  display. 

7.  Level  4  Modules 

This  level  of  modules  controls  the  type  of  track 
uodate,  manual  missile  assignment,  automatic  and  manual 
engaqement  planning,  and  the  display  of  the  engagement  plan. 
These  modules  will  be  used  almost  extensively  for  selecting 
lower  level  modules  to  process  data. 

a.  Type  Track  Module 

Little  is  required  of  this  module.  It  must 
decide  if  a  track  is  being  accessed  for  addition,  deletion 
or  update,  and  then  select  the  proper  lower  level  module. 
One  task  that  might  be  useful  to  incorporate  at  this  level, 
is  to  maintain  a  count  of  the  number  of  active  tracks  in  the 
Engagement  Data  Base.  By  keeping  a  count  at  this  level, 
unnecessary  searching  of  the  data  base  can  be  prevented  when 
a  track  addition  is  needed  and  the  data  base  is  full. 

t.  Launcher  Missile  Assignment  Module 

This  module  is  one  of  the  most  significant. 
It*s  purpose  is  to  allow  the  operator  to  bypass  engagement 
planning  nodules  and  guickly  select  and  launch  the  desired 
missiles.  The  operator  will  have  the  option  of  assigning 
any  missile  to  a  specific  track.  After  launch  the 
Engagement  Data  Base  must  be  updated.  This  may  be  done  by 
updating  the  Launcher  Missile  Status  Data  Base  with  informa¬ 
tion  that  the  cannister  is  now  empty  after  the  missile  has 
teen  fired.  A  drawback  to  this  is  that  by  allowing  the 
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ooeratcr  to  fire  in  this  manner,  he  will  not  be  able  to 
obtain  an  engagement  display  for  this  firing.  The  operator 
may  select  this  module  only  from  the  main  menu. 

c.  Plan  Engagement  Module 

This  module  automatically  generates  the  optimum 
type  enaagement  for  all  designated  tracks  unless  manual 
input  has  been  specified.  The  Launcher  and  Missile 
Assignment  Module  may  also  bypass  this  module  whenever  rapid 
firing  of  a  missile  is  mandated.  Information  will  be 
obtained  from  the  Engagement  Data  Module  and  Probability  of 
Acquisition  Module,  and  a  solution  identified.  The  solution 
will  then  be  entered  in  the  Engagement  Plan  Data  Base.  This 
information  may  be  displayed  by  the  operator,  whenever  he 
desires. 


d.  Threat  Display  Module 

Upon  entry  into  this  module,  the  operator  will 
be  prompted  for  the  method  by  which  desired  information 
should  be  obtained  from  the  Threat  Data  Base  (i.e.,  via  ship 
name,  nationality,  or  ship  class).  After  the  operator  has 
made  his  selection,  the  module  will  access  the  Threat  Data 
Base  in  secondary  storage,  and  display  the  requested  infor¬ 
mation.  The  operator  will  have  the  opportunity  of 
requesting  additional  information  if  he  originally  requested 
information  by  nationality  or  ship  class.  If  the  information 
requested  will  net  fit  on  the  screen,  the  operator  should  be 
able  to  conduct  paging  until  he  obtains  the  necessary  infor¬ 
mation.  He  must  be  allowed  the  opportunity  to  escape  at  any 
time.  The  menu  selection  should  therefore  allow  for  paging 
until  all  the  information  has  been  displayed,  or  the  oper¬ 
ator  has  requested  ar  escape. 
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e.  automatic  Engagement  Display  Module 

Here,  all  information  concerning  the  planned 
engagement  for  a  desired  track  is  displayed.  This  will 
allow  the  operator  tc  see  before  hand  if  the  type  engagement 
is  proper,  and  if  not,  make  the  appropriate  adjustments. 
Information  obtained  from  the  Engagement  Plan  Data  Base  will 
be  passed  to  a  Graphics  Display  module  so  that  the  aczual 
disDlay  may  be  made.  The  reason  for  passing  the  informa¬ 
tion,  instead  cf  displaying  it  immediately  is  that  the 
Manual  Engagement  Display  Module  will  use  the  same  graphics 
module.  The  will  help  prevent  a  duplication  of  code. 

6.  level  5  Modules 

This  level  might  be  considered  the  work  level.  It  is 
here  that  the  majority  of  data  is  added,  deleted  or  changed. 
Information  is  also  obtained  at  this  level  for  forming  an 
automatic  engagement  solution.  The  Graphics  Display  Module 
also  does  all  of  the  work  at  this  level  to  present  the  oper¬ 
ator  with  an  engagement  display. 

a.  Delete  Module 

For  ease  in  deleting  a  track,  the  delete  module 
will  locate  the  desired  track  in  the  Track  Data  Base  and  set 
the  Track  Humber  and  Track  Type  fields  to  zero.  This  will 
cause  the  record  to  become  free  for  future  use.  If  the 
track  is  not  located,  the  operator  must  be  notified,  in  the 
event  that  an  improper  entry  was  made.  There  is  no  need  to 
zero  all  the  fields  in  the  data  base,  since  other  modules 
with  read  access  will  know  by  the  Type  Track  field,  that  the 
record  is  inactive. 
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fc.  Update  Track  Module 


Here  the  operator  must  be  giver,  a  menu  selection 
to  oermit  this  module  to  decide  if  he  wants  to  update  course 
and  speed  and/or  range  and/or  bearing.  He  should  have  the 
capability  of  update  any  or  all.  He  must  then  identify  the 
track  he  desires  to  update.  If  the  update  is  automatic,  the 
Oodate  Track  Module  will  decide  which  lower  level  module  tc 
call . 

c.  Add  Track  Module 

If  the  Add  Track  Module  is  called,  it  will 
search  the  Track  Data  Base  for  the  an  available  Track  Number 
field  to  have  all  zeros.  Zeros  in  the  Track  Number  field 
indicated  the  record  is  free  for  use.  All  information  passed 
will  this  be  placed  in  this  record.  If  no  record  is  avail¬ 
able,  the  operator  will  be  notified,  that  the  data  base  is 
full.  An  additional  requirement  for  the  track  data  base, 
may  be  the  need  to  place  a  priority  on  each  of  the  tracks. 
This  would  allow  the  removal  cf  the  lowest  priority  track  if 
the  data  base  is  full  and  a  higher  priority  track  is 
designated. 

d.  Engagement  Plan  Data  Base  Manager  Module 

The  only  purpose  for  this  module  is  tc  enter 
information  into  the  Engagement  Plan  Data  Base  as  specified 
bv  the  Plan  Engagement  Module.  It  is  the  only  module  to 
have  write  access  to  the  Engagement  Plan  Data  Base.  If  the 
operator  had  decided  cn  a  manual  type  engagement  of  his  own 
while  in  the  Manual  Engagement  Module,  this  information 
would  have  been  passed  up  and  down  through  the  Control 
Module. 


e.  Probability  of  Acquisition  Module 


This  module  will  generate  the  probability  of 
acquisition  by  obtaining  information  from  the  Uncertainty 
Ellipse  Module.  Information  that  must  be  passed  to  this 
module  is  type  missile,  search  pattern,  type  target,  and 
tarqet  ECM  capabilities. 

f.  Graphics  Display  Module 

This  module  will  probably  be  the  most  difficult 
and  cumbersome  module  to  develop.  It  must  be  set  up  to 
display  all  the  information  concerning  engagement  of  all 
targets.  It  must  not  erase  the  information  displayed  by  the 
Track  Display  Module,  and  it  must  be  flexible  enough  to 
handle  use  from  the  Automatic  Engagement  Display  Module  and 
the  Manual  Engagement  Display  Module. 

9 .  Level  6  Modules 

This  is  the  lowest  of  the  module  levels.  At  this 
level  minor  calculations  are  made,  data  is  obtained  from 
several  data  bases,  or  changes  are  made  in  data  bases. 

a.  Course/Speed  Update  Hodule 

If  called  by  the  Update  Track  Module,  the  Track 
Data  Base  will  be  accessed  for  a  course  and/or  speed  change. 
This  module  must  ensure  that  all  entries  to  course  and/or 
soeed  are  within  proper  range.  If  not  the  operator  must  be 
notified  to  reenter,  or  verify  the  the  information  to  be 
correct.  If  the  change  was  requested  by  an  automatic  update, 
and  was  out  of  range,  the  information  must  be  displayed  to 
the  operator,  so  that  corrections  may  be  made  or  the  request 
canceled. 
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b.  Bearing/Eange  Update  Moduls 

This  nodule  will  operate  in  the  sane  manner  as 
the  Update  Track  Module,  except  it  will  only  deal  with  the 
bearing  and/or  range  parameters. 

c.  launcher  and  Missile  Status  Module 

The  launcher  Assignment  Module  nay  obtain  infor¬ 
mation  directly  fron  this  module  in  order  to  select  an 
available  missile  for  immediate  firing.  This  module  will 
access  the  Launcher  Missile  Data  Base  and  permit  the  oper¬ 
ator  to  select  any  nissile  net  inhibited  for  launch.  Once 
the  nissile  is  fired  an  update  nust  be  made  through  the  Plan 
Engagement  Module  in  the  event  that  the  nissile  has  been 
selected  for  another  target  in  the  Engagement  Plan  Data 
Base. 

d.  Threat  Data  Module 

The  only  function  of  this  module  is  to  read  data 
fron  the  Threat  Data  Base,  and  provide  the  information  to 
the  Engagement  Data  Module.  The  module  does  not  have  writs 
capability  for  the  Engagement  Data  Base. 

e.  Uncertainity  Ellipse  Module 

By  taking  parameters  such  as  number  of  missiles 
to  be  fired,  probability  of  acquisition  of  the  target,  and 
lethal  capability  of  the  missile  (s)  being  fired,  this  module 
will  return  ellipses  to  determine  the  uncertainity  of 
locating  the  target  within  each  ellipse.  This  information 
will  be  provided  up  the  line  to  tha  Plan  Engagement  Module 
for  evaluation. 
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B.  SIBOIATIGI  0YBBTIB1 


Since  the  objectives  of  each  module  in  the  simulation 
has  been  established,  an  overview  of  how  the  simulation 
should  interact  with  the  user  is  in  order.  This  overview  is 
not  all  encompassing,  and  should  not  restrict  implementation 
on  a  broader  or  more  conservative  scale.  Specifications  set 
forth  in  Appendix  C  should,  however,  be  maintained  as 
closely  as  possible. 

Immediately  upon  activation  of  the  simulation,  all  data 
bases  will  be  initialized  to  their  default  values.  The  user 
should  not  be  required  to  provide  any  input  to  effect  this 
initialization,  with  the  possible  exception  of  specifying 
the  tyoe  platform  (e.g.,  destroyer,  frigate,  cruiser).  The 
exception  could  be  randomly  generated  to  keep  the  user  from 
always  using  the  same  type  platform. 

After  initialization  has  been  completed,  the  user  will 
be  rrcmpted  for  his  desired  mode  of  simulation:  full  simula¬ 
tion  mode  or  training  mode.  The  only  difference  in  the 
selections  is  that  the  latter  causes  all  changes  to  any  data 
base  to  be  entered  in  a  secondary  storage  file  for  later 
purusal.  The  user  will  then  be  prompted  for  the  current 
time  in  hours,  minutes  and  seconds.  This  information  will  be 
used  to  start  a  real  time  clock.  The  clock  will  time  the 
simulation,  and  provide  random  variants  for  the  generation 
of  shio  sensor,  automatic  input  and  required  manual  input 
data.  This  latter  feature  will  provide  some  sense  of 
realism  by  requiring  some  information  to  be  manually  input 
by  the  user.  Further,  the  use  of  theoretical  frequency  or  a 
probability  distribution  is  considarsd  to  be  more  efficient 
use  of  computer  time  and  memory  storage  requirements  than  a 
canned  table  look-up  procedure. 
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Throughout  the  simulation,  the  user  will  be  randomly 
provided  with  information  concerning  all  of  the  data  bases. 
He  should  have  the  option  to  decide  at  any  time  to  input 
additional  inforaation,  provided  the  input  makes  sense. 
Additionally,  provisions  should  be  provided  to  simulate  the 
failure  of  some  of  the  ship  sensors,  but  not  sufficient 
enough  to  stop  the  siaulation.  An  example  is  simulating 
NTDS  link  failure,  but  then  providing  data  for  manual  input. 
One  final  interactive  feature  that  should  be  provided,  is 
not  allowing  automatic  update  to  the  information  the  user  is 
aanually  updating,  as  opposed  to  information  simply  being 
accessed.  The  siaulation  will  terminate  whenever  all 
■issiles  have  been  fired,  or  only  unlaunchable  missiles 
remain.  The  user  may  also  terminate  the  simulation  at  any 
time. 

One  additional  feature  that  might  be  advisable  to  add  is 
a  "freeze  problem"  feature.  This  would  allow  the  simulation 
tc  be  stopped  during  the  training  mode,  to  allow  the  cper- 
ator  to  evaluate  the  problem.  The  operator  could  then  resume 
the  simulation  at  the  same  point  that  it  was  stopped. 
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If.  SY§J|H  DESIGN  IAHGO&GE  SELECT  101 


An  important  step  in  the  model  simulation  is  the  selec¬ 
tion  of  a  system  design  language.  It's  purpose  should  be  to 
shoe  shat  program  units  are  needed,  and  what  interfaces  each 
unit  requires.  However,  by  selecting  a  system  design 
lanquaqe,  no  restriction  is  placed  on  selecting  an  alterna¬ 
tive  programming  language  for  actual  implementation. 

i.  SELECTION  GOALS 

In  selecting  a  system  design  language,  no  assumptions 
have  been  made  about  the  type  of  computer  that  will  be 
selected  for  i  uplementati  on.  For  the  purpose  of  this 

thesis,  the  selection  of  a  system  design  language  will  be 
based  upon  several  necessary  gualities  for  practical  soft¬ 
ware  engineering.  The  primary  goal  of  the  design  is  that 
the  solution  meet  the  stated  specifications.  This  gcal  is 
rarely  met  if  the  following  software  design  qualities  are 
not  achieved;  modifiability,  efficiency,  reliability  and 
understandabilit y.  The  achievement  of  these  qualities  will 
enhance  the  attainment  of  a  good  simulation  model  as  speci¬ 
fied  in  Chapter  1. 

1 .  Mcdifiabiiiiy 

Although  difficult  to  realize,  the  ability  to  easily 
modify  the  the  software  is  vitally  important,  because  at 
some  point  a  change  in  the  specifications  will  become  neces¬ 
sary.  To  effectively  change  a  system,  the  current  design 
and  code  structure  must  be  maintained.  If  the  structure  is 
maintained  by  "patching1*,  for  example,  further  modification 
effort  rises  exponentially  to  nightmare  proportions. 
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Therefore,  the  selection  of  a  design  language  should  permit 
the  introduction  of  changes  without  increasing  the 
complexity  cf  tha  original  structure. 

Several  principles  directly  support  the  attainment 
of  this  quality.  The  first  is  abstraction.  By  reducing  the 
nuaber  of  details  a  designer  is  required  to  know  and  under¬ 
stand,  at  any  particular  point  in  the  design,  the  system 
becomes  more  structured  and  understandable  and  thus  mere 
maintainable.  When  a  structured  system  has  been  developed 
utilizing  modules  which  are  independent  of  each  other,  modi¬ 
fications  should  not  radically  change  the  overall  structure 
of  the  system. 

Another  principle  which  works  in  conjunction  with 
modularity  is,  localization.  If  modules  are  created  with 
loose  interconnections  and  cohesive  internal  elements,  then 
the  effects  of  modification  can  be  limited  to  a  select  set 
cf  modules. 

Two  other  principles  also  support  modifiability; 
comoleteness  and  confirmability.  When  both  are  used 
toqether,  the  system  may  be  easily  decomposed,  and  therefore 
become  easily  modifiable. 

2  •  Efficiency 

Efficiency  evokes  the  premise  that  all  available 
resources  will  be  utilized  optimally.  In  the  software  sense, 
these  resources  may  be  distributed  between  time  and  space. 
Eoth  are  obviously  somewhat  dependant  upon  the  underlying 
hardware.  Tha  final  design,  in  this  case,  must  be  amenable 
to  real  time  events,  in  order  to  allow  some  sense  of  realism 
when  compared  to  the  actual  system.  For  the  actual  design 
of  this  simulation,  space  resources  should  not  impose  diffi¬ 
culties  since  implementation  is  to  be  made  on  a  large 
comcuter  system. 
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The  principles  which  most  closely  support  this 
quality  include  completeness  and  confirmability. 
Completeness  ensures  that  all  important  elements  are 
present,  permitting  fine-tuning  of  a  low-level  implementa¬ 
tion  without  affecting  higher  level  modules.  Confirmability 
then  allows  for  testing  the  •’improvements"  of  this  find¬ 
tuning,  to  ensure  that  the  system  actually  achieves  the 
stated  goals  of  the  specifications. 

3  .  Rel iabi  1  ity 

Reliability  is  a  crucial  quality  for  the  HWS  system. 
It  is  not  a  quality  which  can  be  built  in  after  design  is 
accomplished;  it  must  be  instituted  from  the  beginning.  In 
the  case  of  the  simulation  model,  if  a  failure  occurs, 
degradation  should  occur  gracefully,  and  not  allow  fatal 
side  effects.  If  monitoring  of  simulated  ship  sensors  is 
taking  place  automatically,  the  loss  of  one  sensor  should 
not  necessarily  cause  the  simulation  to  fail.  In  this  case, 
manual  inputs  could  be  encouraged  through  exception 
handlinq. 

All  of  the  principles  already  discussed  which 
support  modifiability  and  efficiency  also  apply  to  reli¬ 
ability,  but  for  somewhat  different  reasons.  By  applying 
abstraction,  and  the  additional  principle  of  information 
hiding,  only  logical  operations  may  be  accomplished  at  any 
particular  level.  Similarly,  if  modularity  and  localization 
have  been  applied  in  some  purposeful  manner,  then  there  will 
be  limited  interface  between  the  systems  modules,  further 
enhancing  reliability  through  reduced  complexity. 

4 .  Or.derstandab  Hit  y 

In  producing  the  model  translation,  understand- 
ability  is  probably  one  of  the  most  desirable  qualities.  It 
serves  in  managing  the  intricacies  of  software  systems,  by 
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acting  as  a  interlink  between  a  problem  definition  and  an 
appropriate  solution.  tJn  derst aniability  is,  therefore, 
fundamental  to  the  other  qualities  of  modifiability ,  effi¬ 
ciency  and  reliability. 

Every  principle  discussed  thus  far  also  supports 
understandability.  Abstraction  extracts  essential  details, 
while  information  hiding  suppresses  how  they  are  imple¬ 
mented.  Modularity  and  localization  then  places  these 
details  into  some  well  structured  design.  Then  with  another 
principle  of  uniformity,  all  similar  structures  will  be  of 
the  same  logical  design.  Then  with  co mpleteness  and 
confirmability,  all  the  necessary  information  will  be 
present  to  understand  the  system. 

B.  ADA  0VEB7IE! 

Bafore  specifying  Ada  as  the  model  design  language,  an 

overview  of  the  language  is  needed  to  see  if  it  will  meet 

the  selection  criteria.  Part  of  the  criteria  set  forth  by 

the  Ada  designers  was,  program  maintainability,  program 

reliability,  efficiency,  and  consideration  of  programming  as 
a  human  activity.  If,  in  fact,  these  criteria  have  been 
achieved,  then  at  least  on  the  surface,  the  design  criteria 
has  already  been  met.  However,  a  quick  look  at  the  structure 
of  an  Ada  program  might  prove  to  be  a  better  indicator. 

Ada  is  an  extremely  large  language.  It's  purpose  is  to 
be  able  to  respond  to  important  programming  issues  in  prac¬ 
tical,  real  world  systems.  To  facilitate  ease  of  use,  an  Ada 
proqram  consists  of  cne  or  more  units,  where  each  unit  can 
be  comoiled  separately.  To  abstract  further,  each  unit  may 
be  composed  of  any  combination  of  subprograms,  tasks  and 
packages. 
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utilize  the  package  is  presented.  The  body  or  implementa¬ 
tion  is  hidden  from  the  user  since  he  has  no  need  to  know 
how  the  package  is  constructed. 

4.  ether  Ada  Features 

There  are  several  ether  items  in  Ada  that  tend  to 
encourage  selection  cf  Ada  as  the  simulation  model  design 
language.  The  first  is  the  exception  handling  capability.  If 
an  error  (e.g.  ,  divide  by  zerc,  buffer  overflow)  or  failure 
(e.g.,  peripheral  fails),  processing  should  still  continue 
even  at  reduced  capability.  Ada  permits  user  defined  excep¬ 
tions,  as  well  as  some  predefined  exception  conditions.  The 
exception  handler  would  be  ideal  for  describing  situations 
where  simulated  ships  sensors  simulate  failure  conditions. 

The  generic  program  unit  is  another  positive  feature 
for  selecting  Ada.  With  this  tool,  an  algorithm  can  be 
written  to  perform  the  same  operation,  but  on  different  data 
types.  This  feature  would  be  useful  for  describing  situ¬ 
ations  where  single,  or  even  multiple,  fields  of  different 
data  bases  are  updated. 

Globally  assigned  variables  are  also  provided  by 
Ada.  This  would  be  useful  in  identifying  the  current  state, 
for  menu  display  purposes,  for  all  modules  in  the  program. 
However,  if  needed,  packages  could  localize  the  effects  of 
these  variables.  It  is  doubtful  that  many  global  variables 
would  be  needed  for  this  simulation,  but  the  option  is 
available.  However,  extensive  use  of  globally  assigned 
variables  is  considered  poor  programming  practice. 

A  final  feature  is  the  CLOCK  facility.  Host  program¬ 
ming  languages  reguire  access  to  the  operating  system  to 
obtain  time  services,  but  Ada  has  provided  an  avenue  to 
obtain  tiie  information  without  defaulting  to  the  operating 
system.  Since  the  simulation  will  require  the  services  of  a 


real  time  clock,  this  facility  would  lead  to  a  more  under¬ 
standable  simulation  design. 

C.  ADA  AS  THE  SYSTEM  DESIGN  LANGUAGE 

It  is  apparent  that  Ada  holds  all  those  qualities  needed 
in  designing  a  system.  Therefore,  Ada  is  recommended  as  the 
system  design  language. 

Reference  3  established  a  structure  fcr  the  program 
design  as  depicted  in  Figure  4.1.  in  presenting  this  struc¬ 
ture,  tec  modifications  were  made.  First,  the  Launcher 
Missile  Status  was  mewed  under  the  Update  Module,  to  accom¬ 
modate  grouping  of  similar  tasks.  secondly,  the  Threat 
Disolay  was  moved  up  one  level  for  the  same  reason.  The 
overall  structure  continues  to  remain  the  same  as  that  shewn 
in  Figures  2.1  through  2.4. 

Appendix  F  presents  a  generalized,  top-down  type 
approach  in  converting  to  a  system  design  language.  It's 
purpose  is  to  give  a  rough  presentation  of  several  of  the 
structure  modules  of  figure  4.1.  Although  the  semantics  have 
not  been  checked,  the  syntax  has  been  verified.  This  layout 
should  assist  in  the  actual  conversion  from  the  specifica¬ 
tions  to  the  system  design  language. 


7.  COBCIOSIOHS  AND  RECOB  MEN  PATIO  US 


In  developing  a  design  for  a  simulation  model,  in  is 
often  easy  to  loose  track  of  the  original  problem.  This 
thesis  has  attempted  to  establish  a  design  tc  validate  the 
specifications  for  the  HSCLCS  update,  identify  problem  areas 
and  necessary  changes  to  these  specifications.  This  design 
should  ultimately  lead  to  a  verification  of  the  system 
requirements. 

Although  the  intended  purpose  of  the  simulation  is  not 
to  create  a  prototype  of  the  HSCLCS,  it  can  be  used  tc 
develop  such  a  prototype  and,  in  addition,  if  properly 
designed,  be  used  as  a  valuable  training  device.  This 
training  can  be  applied  as  a  method  of  providing  access  to 
the  type  of  information  an  operator  can  expect  to  encounter, 
or  crovide  a  reasonable  facsimile  of  a  real  time  HARPCON 
engagement. 

In  developing  this  design,  several  items  appeared  to  be 
the  most  sionificant.  First  was  the  decision  as  tc  whether 
the  orotlem  could  best  be  solved  by  a  simulation.  Reference 
3  provided  an  analysis  to  help  make  this  decision  in  the 
affirmative.  Next,  was  the  issue  of  narrowing  down  the 
boundaries  of  the  real  system  which  should  be  simulated.  As 
the  modal  design  progresses,  the  need  to  modify  these  deci¬ 
sions  will  undoubtedly  be  required.  This  will  entail 
removing  seme  items,  since  normally  most  designers  tend  to 
incorporate  too  much  vice  too  little.  This  design  will 
surely  support  this  conclusion. 

The  model  specification  was  another  important  issue  that 
this  thesis  had  to  resolve.  To  this  end,  several  concepts 
proved  themselves  invaluable.  The  first  was  abstraction. 
This  allowed  the  identification  of  those  features  of  the 
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real  system  which  were  essential  in  the  model.  Then,  by 
utilizing  the  concept  of  modularity,  each  primary  feature 
was  specified  independent  of  the  specifications  of  any 
ethers. 

A  final  idea  that  was  utilized  at  the  model  specifica¬ 
tion  stage,  was  to  a»cid  restricting  the  implementor.  If  the 
specification  contains  to  much  detail,  an  undue  burden  may 
he  olaced  on  the  actual  implementation.  This  can  produce  a 
model  that  does  not  accurately  reflect  the  system  it  is 
Intended  tc  represent. 

1.  RECOB  ABIDED  FOLLC1-ON  BOGS 

The  author  recommends  exploring  the  following  areas  in 
further  support  of  the  HSCLCS  improvement  and  simulation 
model  design  methodology: 

-  Research  and  develop  the  algorithm  for  the  uncertainity 
ellipse  to  support  the  HSCLCS  simulation  model. 

-  Research  and  develop  the  algorithm  for  the  probability 
of  acquisition  tc  support  the  HSCLCS  simulation  model. 

-  Develop  a  graphics  package  in  support  of  the  HSCLCS 
simulation  model. 

Investigate  different  computer  systems  for  implementa¬ 
tion  of  a  final  design. 

-  convert  the  simulation  model  design  into  the  system 
Design  Language  using  Appendix  F  as  a  guide. 

-  Research  whether  of  aspects  in  this  simulation  which 
might  be  transferable  to  simulation  model  development  of 
other  cruise  missiles  and  their  follow-ons. 

-  study  the  feasibility  of  utilizing  Ada  as  the  program 
design  language,  in  addition  to  the  system  design 
language,  for  the  HSCLCS  simulation  model. 
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JLPPENDII  A 
GLOSSARY 

Data  Ease  -  A  file  of  interrelated  data  stored  together 
to  serve  cne  or  more  applications  and  that  remains  indepen¬ 
dent  cf  programs  using  the  data. 

Data  Structure  -  Dictates  -he  organization,  methods  of 
access,  degree  of  associativity  and  processing  alternatives 
for  information. 

Embedded  System  Pro gra a  -  &  computer  program  that  is 

part  cf  seme  larger  entity  and  essential  to  the  operations 
of  that  system.  Por  example,  the  timer  on  a  washing  machine 
or  the  guidance  system  in  a  missile  may  have  computer 
programs  which  are  considered  to  be  embedded. 

Function  -  Name  given  to  one  or  more  statements  that 
perform  a  specific  task.  Results  in  a  value  being  assigned 
to  its  name  upon  execution  of  that  specific  function. 

Information  Hiding  -  Specification  and  design  cf  modules 
sc  that  information  (procedure  and  data)  contained  within  a 
module  are  inaccessible  to  other  modules  that  have  no  need 
to  know  the  information. 

Interface  -  Communications  between  modules  governed  by  a 
set  of  assumptions  one  module  makes  about  another. 

Hodule  -  A  seperately  addressable  element  with  a  single 
coherent  purpose. 

Modular  Design  -  A  logical  partitioning  of  software  into 
elements  that  perform  specific  functions  or  subfunctions. 

Navy  Tactical  Data  System  -  A  communications  link 
between  different  platforms  (e.g.,  surface  ships  and 
aircraft,  submarines  and  surface  ships)  .  Real  time  informa¬ 
tion  is  passed  via  this  communication  link. 


Package  -  A  pregram  unit  spacifying  a  collection  of 
related  entities  such  as  constants,  variables,  types,  and 
subprograms.  The  visible  part  of  tha  package  contains  the 
entities  that  may  be  used  free  outside  the  package.  The 
private  part  of  the  package  contains  structural  details  that 
are  irrelevant  to  the  user  of  the  package  but  that  complete 
the  specification  of  the  visible  entities.  The  package  body 
contains  the  implementation  of  the  subprograms  or  task 
(cossibly  other  packages)  specified  in  the  visible  part. 

Packaging  -  Alludes  to  the  techniques  used  to  assemble 
software  for  specific  processing  environment  or  to  ship 
software  to  a  remote  location. 

Probability  cf  Acquisition  -  Calculated  probability  of 
seek-head  acquisition  of  intended  target  -based  upon  informa¬ 
tion  available. 

Subordinate  Module  -  A  module  controlled  by  another 
module. 

Subprcgrai  -  An  executable  program  unit,  possibly  with 
parameters  for  communication  with  its  point  of  call.  A 
subprogram  declaration  specifies  the  name  of  the  subprogram 
and  its  parameters;  a  subprogram  body  specifies  its  execu¬ 
tion.  A  subprogram  may  be  a  procedure,  which  performs  an 
action,  or  a  function,  which  returns  a  result. 

System  -  A  collection  of  elements  related  in  a  way  that 
allows  accomplishment  of  some  tangible  objective. 

T^sk  -  A  program  unit  that  may  operate  in  parallel  with 
ether  pregram  units.  A  task  specification  establishes  rhe 
came  of  the  task  and  the  names  and  parameters  of  its 
entries;  a  task  body  defines  its  execution.  A  task  type  is 
a  specification  that  permits  the  subsequent  declaration  of 
any  number  of  similar  tasks.  A  task  is  said  to  depend  upon 
the  unit  in  which  it  is  declared  (subprogram  body,  task 
body,  or  a  library  package  body).  A  unit  is  not  left  until 
all  dependent  tasks  are  terminated.  A  task  is  completed  if 


it  is  waiting  at  the  end  of  its  body  for  amy  dependent  tasks 
cr  is  aborted  bat  net  yet  terminated.  A  completed  task 
cannot  be  called.  A  terminated  task  is,  in  a  sense,  the 
same  as  a  dead  task  in  that  it  is  no  longer  active. 

Uncertainty  Ellipse  -  A  probability  associated  with  a 
track  (or  target)  that  its  position  is  within  a  given 
geographical  location. 


APPENDIX  B 

ACRONYMS  ABO  ABBRBVI ATIOHS 

BIT  -  Built  In  Test 

BOL  -  Eearing  Cnly  Launch 

BBG  -  Bearing 

CBL  -  cannister  Missile  Launcher 

CPU  -  Central  Processing  Unit 

ECO  -  Data  Conversion  Onit 

EPC  -  Data  Processor  Computer 

CDS  -  Graphics  Display  System 

hcc  -  habpcon  Ccntrol  console 

HSCLCS  -  HABPCON  Shipboard  Command-Launch  Control  Set 

HNS  -  habpcon  Weapons  System 

ntds  -  Naval  Tactical  Bata  system 

OLS  -  On-Line-Sizing 

BAH  -  Bandca  Access  Memory 

BBL  -  Bange  and  Bearing  Launch 

BNSH  -  Boyal  Navy  Sublaunched  HARPOON 

STOT  -  Simultanecus  Time-on-Target 

OV-EPBOM  -  Oltra-Niclet  Eraseable  Programmable  Read-Only 

Memory 

BCJP  -  Weapon  Ccntrol- Indicator  Panel 
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ap  perdu  c 

HSCLCS  EIG1GEHEHT  PLAHRING/OPEBATIOIAL  EBPLOYBEBT  FOBCTIOHS 


Operational  Oat a/In formation 

la.  Surface  contact  Position 
(range/fcearing)  .  ■ 

The  use  of  bearing  line  in 
addition  to  the  It  requirement 
reduces  the  number  of  displayed 
surface  contacts  by  two  per 
bearing  line. 

-Designated  Target 
Target  Category  and  Classifi¬ 
cation  Displayed. 

-Unintended  Target  (s) 

Target  Category  and  Classifi¬ 
cation  Displayed. 


Requirement 
Baseline  Design  Goal 
10  20  (min) 


X 


X 


1b.  Surface  Contact/Bearing  Line 


3  (min) 


2.  Own  Ship  Position 


X 


3.  Air  Contact  Position 


3 (min) 


4.  3rd  Party  Targeting  Data  Source  2  3  (min) 

Designation 

WCIP  shall  resolve  target  position 
based  on  range  and  bearing  input 
from  3rd  party  or  bearing  lines 
from  3rd  parties  or  own  ship. 

-Hanual  Entry  of  Bearing  Lines  X 

-Hanual  Entry  of  Bangs  and  Eearing  X 


i 

f 

i 


B 


5.  Target  classification 
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X 


-Large  (default) 

Larger  than  a  patrol  boat. 

-Snail  X 

Patrol  boat  or  smaller. 

6.  Cent  act /Track  Course  Direction 
Indicator 

Prcgraa  automatically  compensates 
for  own  ship's  notion. 

-Direction  Indicator  X 

-Dead  Beckoning  (Cen  Ship  Only)  X 

7.  Contact/Track  Targeting  Data  Source 

-Manual  Input  X 

iith  appropriate  data  source  error; 


includes  3rd  party. 

-Automatic  Input 

-MTDS  X 

-5AEAH  X 

-SOHAH  X 

-EH/ESH  X 

-Target  Designation  System  X 


8.  Bind  Earaaaters  (relative) 


-Speed 

-Actual  X 

Manual  input. 

-Default  value  X 

-Direction 

-Actual  X 

Manual  input. 

-Default  value  X 

9.  Temperature 

-Actual  X 

Manual  input. 

-Default  value  X 
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X 


10.  Precipitation 
-Yes 

Manual  input. 

-No  (default  value)  X 

11.  Operator  Cues/Lockouts 

-launch  Inhibited  (lockouts/cue)  X 

All  launch  inhibits  except  roll/ 
pitch  cutout. 

-Missile  Heady  (cue)  X 

-Data  Age  (cue)  X 

Target  and  envircrmenta  1  data. 

-Missile  Launch  Status  (cue) 

-Cell/Bail  Empty  (missile  away)  X 

-Missile  Dud  Declaration  X 

-New  Contact/Track  to  be  Input  (cue)  X 

-Illeqal  Action  (lockout /cue)  X 

12.  Tiee/Clock 

-ZOLO  Tine  X 

Start  clock:  Automatic  entry  via 
NTDS  Interface  and/or  manual  entry. 
-Time  on  Target  X 

Manual  entry. 

-Time  cf  Launch  X 

Computation. 

-Countdown  X 


Includes  Time-to-Pire  and 
Time-tc- Impact. 

13.  Loadout  St  at  us/ Missile  Variant 
Identification 

-Easeline/Block  I  Tactical  Missile  X 

(BGN-84A) 

-Hoyal  Navy  Submarine  HABP00N  X 

(EGH-84B) 
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When  reconfigured  for  surface 
launch. 

-Block  IE  Tactical  Missile 
(BGM-84C) 

-Block  IC  Tactical  Missile 
(BG8-84D) 

-suoplemental  Identification 
(aanual  entry:  info  froa  loadout 
lcgbocks  of  hybrid/nonstandard 
seeker-MGO  combinations). 

-Training  All-Up  Bound  (BTM-84  A/C/D 
and  BNSH) 

14.  Missile  In-Plight  Tracks 

15.  Op  tc  180  degree  Cff-Axis  Launch 


Ooerational  Selections 

1.  Beference  System 

-True  Target  Bea ring/Bel a time  Target  X 
Bange 

Tcp  cf  display  is  north. 

-NTDS  Grid 

-Geographic  (latitude  &  longitude) 

2.  Planned  Missile  Plight  Path  3 

Software  to  ensure  that  no  flight  W 
path  may  be  selected  which  could 
result  in  the  acguisition  of  own 

ship. 

3.  Search  Mode  Selection 

-On  Line  Sizing  (default)  w/Hanual  l 

Override 

On  Line  Sizing  shall  be  automat¬ 
ically  selected  if  BBL  or  BOL  are 
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not  selected. 

•-Bangs  and  Bearing  Launch  (BBL) 

BBL  pattern  size  shall  be  a 
function  of  total  flight  path 
(range  traveled  to  target)  . 

-Bearing  Only  Launch  (BOL) 

Selectable  Search  Pattern  Expansion 
(0  -  360  degrees) 

For  BGH-84D  irissile  only,  applies 
to  HBL  node  and  On-Line -Sizing 
(CLS)  which  results  in  an  BBL 
search  pattern. 

-Normal  Center  Expansion 
For  BGM-84A/BGH-  64B/BGH  -84  C 
aissiles;  default  for  BGH-84D 
aissile. 

Enable  and  Dastruct  Banges  BOL 
Default  values  or  manual  entry 
(ranqes  not  supplied  over  NTDS 
interface)  . 

High  Altitude  Hold 
BGH-04D  only. 

-He  Entrv;  Default 
The  High  Altitude  Hold  default 
ranqe  net  to  interfere  with  search 
initiation  and  not  to  exceed  lOna; 
i.e..  High  Altitude  Hold  range  is 
set  to  the  minimum  of  lOnm  or  range 
to  search  initiation. 

-Hanual  Entry 

The  selected  High  Altitude  Hold 
range  must  be  less  than  the  range 
to  search  initiation. 


Presearcb  Ply-Out 
Sea  Skin  (RGH-84D  only) 

Default  node  -  Presearch  Ply-Out  is 
set  to  sea  skin  altitude  following 
the  High  Altitude  Hold. 

Hanual  Entry 

Presearch  Ply-Out  at  nornal  HARPOON 
run-in  altitude  as  used  in  current 
HSCLCS. 

Terninal  Attack  Eode  (RGH-84D  only) 
Sea  Skin  (default) 

-Pop-up 

Default  override  fcy  manual  selec¬ 
tion  Cf  pop-up,  "SHALL  TARGET" 
designation  by  NTDS,  or  when 
"SHALL  TARGET"  is  entered  aanually. 

Hissile  Assignment  for  Engagement 

Planning 

Hanual  entry. 

Hulti-Hissile  Engagement  cf 
Designated  Target. 

Baseline:  Op  to  4  missiles  frcn  a 
single  launcher.  (Note:  Single 
launcher  includes  TARTAR  and 
ASROC).  Design  Gcal:  Op  to  8 
missiles  from  2  CHL's. 

Salve  Hissiles  Against  One  Target 
Por  Simultaneous  Arrival  (STOT 
Salvo) . 

Operator-planned  engagement. 

-Salvo  Against  Op  to  Pour  Targets 
(single  air  point)  Prom  One  Launcher 
Por  Simultaneous  Arrival  (STOT 
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Salve) . 

Sams  aimpoint  and  a  different  RBL 
search  expansion  for  each  RGM-84D 
missile  in  order  to  distribute 
salvoed  missiles  among  the  targets 
in  a  formation. 

-Ripple  Salvo  as  per  current  HSCLCS 
CBL  configuration. 

-Quick  Reaction/Preprogrammed  STOT 
Salvo. 

Modified  HSCLCS  automatically  will 
calculate  and  enter  a  different 
waypeint  for  each  RGM-84D  missile 
in  a  quick  reaction  salvo  for 
simultaneous  time-on-ta rget  (STOT). 

11.  Background  data  and  sector  data 
request. 

0 sable  with  NTDS  interface  only. 
ENGAGEMENT  DISPLAYS 

1.  Contact/Ttack  Oncertainity  Ellipse 
-Designated  Surface  Target 
-Unintended  Targets 

If  selected  by  operator. 

2.  Predicted  Time-or-Targe  t 

3.  Probability  of  Acquisition 
Numerical  value. 

-Designated  Targets 
-Unintended  Targets 
If  selected  by  operator. 

a.  Seeker  Search  Pattern  Outline 
For  selected  search  mode. 


X 


5.  Missile  Flight  Path 
Fcr  all  selected  missiles. 

6.  Booster  Drop  Zone  X 

7.  Missile  Power  Application  Warning  X 


OTHER 

1.  Test/Haintenance 
-Missile  BIT  Besults 

-Go/Nc-Go  Indication  X 

-Failure  Status  Code  X 

- HSCLCS  BIT  Results 

-Go/No-Go  Indication  X 

-Failure  Status  Cede  X 

2.  Training  Mode 


,  Inherent  capability  provided  by 
system  design.  Design  to  utilize 
data  from  NTDS  and/or  external 
training  support  devices  via  an  RS 
222  serial  interface. 

-Contact/Track  Location  (actual  or 
simulated)  . 


-Cff  Board  Source/NTDS  X 

-Own  Ship  Sensor s/NTDS  X 

-Manual  Input  X 

-Own  Ship  Position  (actual  or  siaul-  X 

ated) . 

-Training  Scenario  Parameters 
-Environmental  Conditions  X 

-Operational  Planning  Selections  X 

3.  Data  Extract 

Design  to  be  compatible  with  a;?  RS 


232  serial  interface  to  provide  for 
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data  storage/display  in  off-line 
devices  (e.g.,  tape  cassette  recor 
der)  . 

-Target/Targeting  Eata 
-Hissile  Initialization  Data 
-BIT  Results 

Ba-jor  Display  Features 
-Variable  Range  Scale 
16K-,  32K-  ,  64 K-  ,  128K- ,  192K-,  or 
256K-yard  radius.  The  2  56K-yard  is 
the  default  scale. 

-Offset 
—  2  COB 

8K-,  16 K-  or  32K-yard  radius. 
-Special  Symbols 

-Cursor,  with  Bearing/Range  readout 
Manually  controlled. 


IP£1HDIX  D 

Dill  BASE  DESCRIPTION 

This  appendix  contains  the  data  base  descriptions  to  be 
used  in  the  simulation  model.  These  data  bases  include: 

1.  Environmental  Data  Base 

2.  launcher  and  Hissile  Status  Data  Base 

3.  Benu/state  Data  Base 

4.  Ship  Parameter  Data  Base 

5.  Threat  Data  Base 

6.  Engagement  Data  Base 

7.  Track  Data  Base 
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1.  Data  Base  Sane:  ESVIHO NMENTAL  DATA  BASE 

2.  Pamose:  This  data  base  contains  the  current  s^a^re  of 

weather;  visibility,  sea  state,  vrr.ds,  ram, 

etc. 

3.  Data  Base  Users: 

a.  Brite  Access:  Environment  Data  Base  Manager 

b.  Bead  Access:  Environment  Display 

Plan  Engagement 

a.  Data  Base  Elements:  Visibility 

Sea  state 

Mind-direction  and  speed 
Helative  Humitity 
Te  mpe  rature 
Barometric  Pressure 
Precipitation 

5.  Operation  on  Data  Base:  Update  (manual  or  automatic) 

-  Add 

-  Delete 

-* Change  all  elements 
Display 


Data  Base  Name:  LAUNCHER  AND  MISSILE  STATUS  DATA  BASE 
Pumose:  This  data  base  will  keep  track  of  the  number 
and  type  of  missiles  a7ailable  for  launch. 
The  data  base  will  be  updated  by  feedback  from 
the  launcher. 

Data  Base  Users: 

a.  Brite  Access:  Launcher  Missile  Status 

b.  Read  Access:  Launcher  Missile  Assignment 

Plan  Engagement 

Launcher  Missile  Status  Display 
Data  Ease  Elements:  Launcher  Number 

Cannister  Number 
Missile  type 
Launch  Inhibit 

Operations  on  Data  Base:  Update  -  Add 

-  Delete 

-  Change  all  elements 


Display 


for 


1.  Data  Base  Name:  HEN  0/S  TATE  DATA  BASE 

2.  Purpose:  This  data  base  will  contain  the  menus 

program  operation  and  also  provide  the  states 
allowable  from  any  operation.  That  is  it  will 
provide  the  menus  necessary  to  access  all 
aspects  of  the  program. 

3.  Data  Base  Osers: 

a.  Rrite  Access  :  None 
t.  Read  Access:  Display  Module 

a.  Data  Ease  Elements:  On  determined  at  this  time 
5.  Operations  on  data  Base:  Operator  can  select  desired 

menu  item 
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Data  Base  Haas  :  SHIP  PARAMETER  DATA  BASE 
PurDOse:  This  data  base  will  maintain  all  pertinent 
information  pertaining  to  one's  own  ship.  The 
design  allows  for  this  information  to  be  input 
manually  or  automatically. 

Data  Base  Users: 

a.  arite  Access:  Ship  Parameter  Data  Base  Manager 
fc.  Read  Access:  Update  Track 

Plan  Engagement 

Ship  Parameter  Display 

Data  Ease  Elements:  Course 

Speed 
Latitude 
.  Longitude 

Operations  on  Data  Base  :  Update 

Display 


-  Change  all  elements 


1.  Data  Ease  Name:  THREAT  DATA  BASE 

2.  Purocse:  This  data  base  is  to  contain  a  list  of  hostile 

surface  vessels  by  name  and  class.  Associa  wed 
with  each  class  of  vessel  will  be  the  weapons 
platform,  ECM  capabilities,  and  optimum 

engagement  plan  for  attacking  that  vessel. 
(The  security  of  this  information  must  be 
considered  when  designing  the  Threat  Display 
and  Threat  Data  Base  Manager  modules)  . 

3.  Data  Base  Users: 

a.  Write  Access:  Threat  Data  Base  Manager 

b.  Read  Access:  Threat  Display 

Analyze  Threat  Data 

4.  Data  Base  Elements:  Ship  Name 

Nationality 
Ship  Class 
weapons 
ECM  Equipment 

Engagement  Plan  Recommended 

5.  Operations  on  Data  Base:  .  Update  -  Add 

-  Delete  (Permissions) 

-  Change  all  Elements 

(Permissions) 

Display 


y 
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1.  Data  Base  Nana:  ENGAGE  BENI  DATA  BASE 

2.  Purpose  :  This  data  base  will  contain  a  track  name  and 

associated  engagement  plans  for  that  track. 
The  engagement  plan  may  be  generated  automat¬ 
ically  by  the  computer  or  manually. 

3.  Data  Base  Users: 

a.  Write  Access:  Calculate  Probability  of  Acquisition 

b.  Bead  Access  :  Engagement  Plan  Display 

4.  Data  Ease  Elements:  Track  name 

Type  of  engagement  plan  (manual  or 
au  tomatic) 

Number  of  missiles  to  fire 
Seguence  of  firing  missile(s) 

Type  of  missile  to  use 
Flight  path 
Wa  ypoints 

5.  Operations  on  data  base:  Update 

Display 
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1.  Data  Base  Naae:  TRACK  DATA  BASE 

2.  Purpose:  This  data  base  will  contain  the  posiricn  of 

all  tracks  and  pertinent  information 

pertaining  to  the  track. 

3.  Data  Base  Users: 

a.  Hrite  Access :  Delete  Track 

Add  Track 

Course  and  Speed  Update 
Bearing,  Range  and  Position  Update 

b.  Read  Access:  Display  Track  Data 

Plan  Engagement 

4.  Data  Ease  Elements:  Type  track  (friend  or  foe) 

Class  of  vassal 
Bearing 
Ra  nge 

Position  (lattitude  and  longitude) 

Course 

Speed 

5.  Operations  on  Data  Base:  Update  -  ad*d 

-  delete 

-  change  bearing  range 
or  position 

Display 


77 


kimm  s 

MODULE  DESCHIPTIOIS 


This  appendix  contains  the  nodule  descriptions  of  the 
■odules  shown  in  Figure  2.1  through  Figure  2.4.  These 
modules  include: 


2. 1. 1 
2. 1.2 
2.1.2.  1 
?. 1.2.2 
4.  1  .  J 

3.  1 
3.  1.2 

3.2 

3.  2.  1 

3.2.2 

3.2.2.  1 

3.2.3 

3.2.3.  1 
4 

4.  1 

4.2 

4.3 

4.4 
4.4.  1 

4.4.2 
4.4.2.  1 

4.4.3 

4.5 

4.6 


Control 
Process  Input 

Ship  Parameter  Data  Base  Manager 

Environmental  Data  Base  Manager 

Threat  Data  Base  Manager 

Convert  coordinates 

Type  Track 

Delete  Track 

Update  Track 

Course  and  Speed  Update 

Bearing#  Eange,  ana  Position  Update 

Add  Track 

Launcher  and  Missile  Assignment 
Launcher  and  Missile  Status 
Plan  Engagement 

Plan  Engagement  Data  Base  Manager 
Engagement  Data 
Threat  Data 

Probability  of  Acquisition 
Uncertainty  Ellipse 
Display 
Menu  Display 

Launcher  ana  Missile  Status  Display 

Environmental  Display 

Engagement  Display 

Threat  Display 

Automatic  Engagement  Display 

Graphics  Display 

Manual  Engage  tent  Display 

Ship  Parameter  Display 

Track  Display 
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1. 

2. 


3. 


4. 

5. 


Module  Name:  CONTROL,  NUMEER  0 


Module  Purpose: 


The  Control 
nodules  and 
flow. 


module  calls  all  ether 
determines  the  program 


Subordinate  Modules: 


Process  Input.  (1) 
Launcher  Missile 
Plan  Engage mant 
Display  (4) 


Assignment 
(3.  2) 


(3.  1) 


Cblects  Used  by  the  Module:  Manual  inputs 

Operations  Module  Performs:  Selection  of  subordinate 
unr.oiivua  modules  to  perform  program 

operation. 


1. 

2. 


3. 


4. 


Module  Name:  PROCESS  INPUT,  NUMBER  1 
Module  Purpose: 


Selects  subordinate  module  to  update 
corresponding  data  bases. 


Subordinate  Modules: 


Manager 

Manager 


Ship  Parameter  Data  Base 

(1.1) 

Environmental  Data  Base 

/ 1,2) 

Convert  Coordinates  (2) 

Threat  Data  Base  Manager  (1.3) 

Otlects  Used  by  the  Module:  Manual  Inputs  to  update 

modu les 


Selects  appropriate 
dinate  module  to 
corresponding  data 


subor- 

update 

base. 


i 


Operations  Module  Performs: 


NUMBER 


1.  Module  Name:  SHI?  PARAMETER  DATA  BASE  MANAGER , 

t.  1 

2.  Module  curpose:  Update  the  Ship  Parameter  Data  Base  by 

either  manual  or  automatic  means. 

3.  Subordinate  Modules:  None 

4.  Objects  Used  by  the  Module:  Ship  parameter  input  data 

5.  Operations  Module  Performs:  Update  of  the  Ship 

Parameter  Data  Base. 


1.  Module  Name:  ENVIRONMENTAL  DATA  BASS  MANAGER,  NUMBER 

1.2 

2.  Module  Purpose:  Update  the  Environmental  Data  Base  by 

either  manual  or  automated  means. 

3.  Subordinate  Modules:  None 

4.  Objects  Used  by  the  Module:  Environmental  input  or 

update  data. 

5.  Operations  Module  Performs:  Update  of  the  Environmental 

Data  Base. 


1.  Module  Name:  THREAT  DATA  BASE  MANAGER,  NUMBER  1.3 

2.  Module  Purpose:  Update  the  Threat  Data  Base  by  either 

manual  means  or  through  the  use  of  a 
standard  chip  that  can  be  periodically 
updated  and  sent  to  all  ships  with 
HARPOON  capability. 

3.  subordinate  Modules:  None 

4.  Objects  Used  by  the  Module:  Data  used  to  update  the 

Threat  Data  Base. 

5.  Operations  Module  Performs:  Update  of  the  Threat  Data 

Base. 
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Hodule  Name:  CONVERT  COORDINATES ,  NUMBER  2 

Module  Purpose:  To  convert  all  inputs  to  update  track 

data  to  common  coordinates.  The  inputs 
can  be  manual,  from  own  ship's  tracking 
equipment,  or  from  a  NTDS  link  from 
ether  platforms. 

Subordinate  Modules:  Type  Track  (2.1) 

Objects  Used  by  the  Module:  information  used  to  update 

the  Track  Data  Base, 
bearing,  range  and  posi¬ 
tion  . 

Operations  Module  Performs:  All  sources  of  input  for 

the  Track  Data  Base  are 
converted  to  common  coordi¬ 
nates  whether  they  are 

manual,  NTDS  or  from 

another  source. 


Module  Name:  TYPE  TRACK,  NUMBER  2.1 

Module  Purpose:  Type  Track  determines  if  the  track  is 

to  be  deleted  from  the  database,  added 
to  the  database,  or  some  parameters  of 
a  oresent  track  are  to  be  altered. 
These  actions  are  performed  by 

selecting  the  appropriate  subordinate 
tod  ule  . 

Subordinate  Modules:  Delete  Track  (2.1.1) 

Update  Track  (2.1.2) 

Add  Track  (2.  T.3) 

Objects  Used  by  the  Module:  Classification  of  type 

urlate  to  be  performed; 

addition,  deletion  or 

alteration  to  the  Track 
Data  Base. 

Operations  Module  Performs:  Selection  of  delete, 

update,  or  add  track  subor¬ 
dinate  modules  based  on 
track  type. 


Module  Nans:  DELETE  TRACK,  NUMBER  2.1.1 

Module  Purpose:  To  eliminate  cracks  from  the  data  base 
no  e  ruLywwB  tiiat  the  operator  determines  are  no 

longer  useful. 

Subordinate  Modules:  None 
Objects  Used  by  the  Module:  None 

operations  acdule  Perforas:  Irac^  ^1 

removed  from  the  Track  Data 
Base . 


Module  Name:  UPDATE  TRACK,  NUMBER  2.1.2 

Module  Purpose:  To  update  the  information  contained  on 
^  tracks  m  the  Track  Data  Base. 

Subordinate  Modules:  Course  and  Speed  (2. 1.2.1) 

Bearing  and  Range  (2. 1.2.2) 

Objects  Used  by  the  Module:  Bearing  .and  range  from  a 

J  fl  TT5>n  Dfl'  nt. 


Operations  Module  Perforas: 


Bearing  and  range  from  a 
fixed  point. 

Elapsed  time.  ,  , 

Own  ship  course  and  speed. 
Target  course  and  speed. 

Detarmines  which  subordi¬ 
nate  module  is  to  be  called 
to  perform  the  desired 
update. 


• -.v-  .> 


1.  Module  Name:  COOBSE  AN  E  SPEED  UPDATE,  NUMBER  2. 1.2.1 

2.  Module  Purpose:  To  update  the  course  and  speed  infcrma- 

i.  nouux*  rui^  t£cnr  or  9ach  tracic  contained  m  the 

Track  Data  Base. 

3.  Sutordirate  Modules:  None 

4.  Objects  Used  by  the  Module:  Own  ship  cpurse  and  speed. 

Ellapsed  time. 

Bearing  and  range  from  a 
fixed  point. 

NTDS  link  information. 

5.  operations  Module  Performs:  Determines  course  and  speed 

of  tracks  based  on 
bearing/range  and  ellapsed 
time  when  entered  manually 
and  updates  Track  Data 
Base.  with  automated  . track 
information  available 

(e.g.,  NTDS)  module  updates 
Track  Data  Base  with  the 
given  course  and  speed. 

1.  Module  Name:  BEARING.  RANGE,  AND  POSITION  UPDATE, 

NUMBER  2.  1.2.2 

2.  Module  Purpose:  To  update  the 

tion  (latitude 
tion  on  each 
Track  Data  Base 

3.  subordinate  Modules:  None 

4.  Objects  Used  by  the  Module:  Own  ship  sensor  informa¬ 

tion  • ,  .  ,  .  _ 

NTDS  link  information 

5.  Operations  Module  Performs:  Determine?  bearing/range 

and  position  of  tracks 
based  on  owr.  ship  sensgr 
information  and  own  ship 
position,  when  entered 
manually  and  updates  Track 
Data  Base.  With  automated 
track  information  available 
(e.g.,  NTDS)  module  updates 
Track  Data  Base  with  the 
given  bearing/range  and 
posi tion. 


bearing/range  and  posi- 
and  Longitude)  mforma- 
track  contained  in  the 
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1.  Module  Name:  ADD  TRACK ,  NUMBER  2.1.3 

2.  Module  Purpose:  To  allow  new  tracks  to  be  inpur  into 

the  Track  Dana  Base. 

3.  Subordinate  Modules:  None 

4.  Objects  Used  by  the  Module:  Course,  speed,  bearing, 

range,  position,  identifi¬ 
cation  of  track  (friend  or 
foe  and  ship  class)  . 

5.  Operations  Mcdule  Perforis:  Permits  the  addition  of  new 

tracks  into  the  Track  Data 
Base. 


1.  Module  Name:  LAUNCHER  MISSILE  ASSIGNMENT,  NUMBER  3.1 

2.  Module  Purpose:  Allow  the  operator  to  bypass  the 

engagement  planning  capabilities  of  rhe 
computer  system  and  simply  select  and 
launch  the  desired  missiles. 

3.  Subordinate  Modules:  Launcher  and  Missile  Status 

4.  Objects  Used  by  the  Module:  Ijjpups  fro?  operator  iden¬ 

tifying  which  launcher  and 
missiles  to  be  fired  in 
which  bearing,  range  and 
waypoints  if  desired. 

5.  Operations  Module  Performs:  The  Launcher  Missile 

Assignment  module  allows 
the  operator  to  manually 
select  a  launcher  ana 
missile  to  be  fiped  in  a 
given  direction  similar  to 
the  present  capabilities  of 
the  HARPOON  Weapons  System. 
The  automated  engagement 
planning  functions  of  this 
program  are  bypassed. 


1. 


Hod  ala  Haas: 


2. 


LAUNCH SB  AND  MISSILE  STATUS,  NUMBER  3.1.2 


Module  Purpose: 


Jo  provide  current 
launchers  (port 
ready  to  fire  and 
missiles  are  ready 


informal icn  on 
and  starboard) 
which  and  what 
for  firing. 


what 

are 

type 


3.  subordinate  Modules:  Ncne 

4.  Ob-jects  Used  by  the  Module: 

5.  operations  Module  Performs: 


firing. 


The  Launcher,  and  Missile 
Status  nodule  receives 
automated  inputs  from  each 
launcher  on  the  .status  and 
type  of  all  missiles.  This 
information  is  used  to 
update  the  Launcher  and 
Missile  Status  Da*a  Base. 
When  queried  by  either  the 
Launcher  and  Missile 
Assignment  module  or  the 
Enqaqement  Data  mgdule#  the 
Launcher  and  Missile  Status 
module  can  return  the 


miss iles. 
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1.  Module  Name:  PLAN  ENGAGEMENT,  NUMBER  3.2 


2. 

3. 


4. 

5. 


Module  Purpose:  To  determine  the  optimum  engagement 

Flan  for  a  given  target. 


Subordinate  Modules: 


Pla^  Engagement 

Engagement  Data 
Probability  of 


Data  Base  Manager 
(3.  ?.?)  . 

Acquisition  (3.2.3) 


Objects  Used  by  the  Module:  Which  track  to  plan  the 

engagement  for. 

Operations  Module  Performs:  Ths  Plan  Engagement  module 

is  the  heart  of  this  soft¬ 
ware  program.  This  module 
determines  an  optimum 
engagement  plan  for  desired 
targets.  The  targets  that 
have  an  engagement  plan 
computed  can  be  identified 
either  by  a  selective 
manual  input  or  can  be 
automatically  generated  for 
all  contacts  that  are  clas¬ 
sified  hostile  (This  latter 
process  would  require  a 
slight  modification  to  the 
design;  an  input  to  the 
Plan  Engagement  must  be 
received  from  the  type 
track  module) .  Through 

access  to  the  Threat  Data 
Base,  Launcher  Missile 
Status  Data  Base  ,  the 
optimum  plan  for  engaging  a 
selected  target  can  be 
computed.  The  functions 
performed  by  this  module 
can  greatly  assist  the 
Tactical  Action  Officer  in 
the  performance  of  his 
duties . 
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1.  Nodule  Name:  PLAN  ENGAGEMENT  DATA  BASE  MANAGES,  NUMBER 

3.  2.1 


2.  Module  Purpose:  To  update 

Ease. 

3.  Subordinate  Nodules:  None 

4.  oblacts  Used  by  the  Nodule: 

5.  Operations  Nodule  Perforas: 


the  Engagement  Plan  Data 


Engagement  plan  as  gener¬ 
ated  by  the  Engagement  Plan 
Nodule. 

The  Plan  Engagement  Data 
Base  Manager  enters  all 
engagement  plans  that  the 
Plan  Engagement  module 
generates  into  a  Plan 
Engagement  Data  Base.  This 
way  a  list  of  the  engage¬ 
ment  plans  for  all  appli¬ 
cable  targets  is  kept 
current  in  a  data  base. 


1. 

2. 

3. 

4. 


Nodule  Name:  ENGAGEMENT  DATA,  NUMBER  3.2.2 

Nodule  Purpose:  The  Engagement  Data  module  supplies  the 

data  needed  by  the  Plan  Engagement 
module  to  generate  the  Engagement  Plan. 


Subordinate  Nodules: 


Launcher 
<  3. 1  .2) 
Threat  Data 


and  Missile 
(3.2.2.  1) 


Status 


Objects  Used  by  the  Module:  Which  launcher  and  missiles 

arer  ready  to  fire. 

All  pertinent  information 
on  hostile  ship  class, 
weapons,  ECM  equipment  and 
best  strategy  for  attack 
contained  in  the  Threat 
Data  Base. 


5.  Operations  Nodule  Performs:  The  Engagement  Data  module 

coordinates  the  passing  cf 
all  data  base  information 
needed  to  generate  an 
engagement  plan  to  the  Plan 
Engagement  module.  In  this 
desigp,  that  information  is 
contained  m  the  Launcher 
and  Missile  Status  module 
and  the  Threat  Data  module. 
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1. 

2. 


3. 

4. 


5. 


Module  Name:  THREAT  DATA,  NUMBER  3.2. 2.1 


Module  purpose: 


To  provide  the 
the  Threat 
Engagement  Data 


information  contained 
Data  module  to 
module  when  requests 


in 

the 

d. 


Subordinate  Modules:  None 
Objects  Used  by  the  Module: 


Operations  Module  Performs: 


All  elements  contained  in 
the  Threat  Data  Base,  ship 
class,  weapons,  platform, 
ECM  capability  and  best 
plan  for  attacx. 


The  Threat  Data  module 
provides  t he  .  Engagement 
Plan  moduls  with  alX  of  the 
information.  that  xf 
contained  m  the  Threa. 
Data  Base.  This  informa¬ 
tion  is  then  used  to  deter-*- 
mine  the  optimum  engagement 
plan. 
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Nodule  Mane:  PROBABILITY  OP  ACQUISITION,  NUMBER  3.2.3 

Nodule  Purpose:  To  determine  wh$t  tlje  probability  is 

that  if  a  missile  is  launched  at  a 
given  target  that  the  missile  can 
acquire  ana  hit  that  target. 

Subordinate  Nodules:  Uncertainty  Ellipse  (3.  2.3.1) 

Objects  Used  by  the  Nodule:  The  figgre  generated  by  the 

Uncertainty  Ellipse  module. 
Type  missile  to  be  launched 
ana  search  pattern. 

Type  target  to  be  attacked 
ana  its  physical  character¬ 
istics  ana  ECN  capabili¬ 
ties  . 

Operations  Nodule  Performs:  Tha  Probability  of 

Acquisition  module  uses  the 
type  missile  fired,  range 
to  target,  and  target  char¬ 
acteristics  to  generate  the 
probability  that  the 

missile  can  acquire  and  hit 

the  given  target.  This 

information  along  with  the 
value  obtained  from  the 
Uncertainty  Ellipse  module 
is  then  passed  to  the  Plan 
Engagement  module  where 

they  become  elements  of  the 
engagement  plan  maintained 
in  the  Engagement  Plan  Data 
Base. 


Hodul€  Name:  UNCERTAIN  TY  ELLIPSE,  NUMBER  3.2.3.  1 


Subordinate  Modules:  None 
Objects  Used  by  the  Module: 


Operations  Mcdule  Performs: 


Number  of  missiles  to  be 

Probability  cf  acquisition 
of  the  target. 

Lethal  capability  of 
missiles  fired. 

The  Uncertainty  Ellipse 
module  takes  the  number  and 
capabilities  of  missiles 
fired  and  combines  these 
values  with  the  probability 
of  acquisition  to  generate 
the  probability  of  a  target 
kill.  The  Uncertainty 


probabilities  st ating”  t hat 
total  destruction  .of.  the 
target  will  occur  if  it  is 
within  one  ellipse,  50* 
disability  of  .the  target 
will  occur  if  it  is  within 


will  occur  if  it  is  within 
a  second  ellipse,  etc. 
These  ellipses  will  account 
for  the  fact  that  hostile 
target  positions  may  net  be 
completely  accurate. 


1.  Module  Name:  DISFLAY,  NUMBER  4 

2.  Modula  Purpose:  To  call  subordinate  nodules  as  neces¬ 

sary  to  generate  required  displays. 

3.  Subordinate  Hodules:  Menu  Display  (4.1) 

Launcher  ana  Missile  Status 
Display  (4.2) 

Environmental  Display  (4.3) 
Engagement  Display  (4.4) 

Ship  Parameter  Display  (4.5) 

Track  Display  (4.6) 

4.  Objects  Used  by  the  Module:  Display  requests. 

5.  Operations  Module  Performs:  The  Display  module  calls 

the  required  modules  to 
generate  display  as  neces¬ 
sary. 


1.  Module  Name:  MENU  DISPLAY ,  NUMBER  4.1 

2.  Module  Purpose:  To  access  the  Menu/State  Data  Base  and 

display  the  required  menu  when  called 
and  keep  track  of  the  state  of  the 
progra  a. 

3.  Subordinate  Hodules:  Hone 

4.  Objects  Used  by  the  Module:  Information  contained  in 

the  Menu/State  Data  Base. 

5.  Operations  Module  Performs:  T^e  Menu  Display  module 

will  access  the  Hepu/State 
Data  Base  and  provide  the 
necessary  menu  for  display 
when  prompted  by  the 
Display  module.  The  Menu 
Display  module  will  also 
keep  track  of  the  state  of 
the  program,  that  is  what 
menus  can  be  displayed 
given  that  the  state  of  the 
program  exists  now  with  a 
current  menu. 


1.  Nodule  Name  :  LAUNCHES  AND  MISSILE  STATUS  DISPLAY, 

NUMBER  4.2 

2.  Nodule  PurDose:  To  access  the  Launcher  and  Missile 

Status  Data  Base  and  provide  a  display 
of  the  information  contained  in  -hat 
data  base. 

3.  Subordinate  Nodules:  None 

4.  Objects  Used  by  the  Nodule:  Information  contained  in 

the  Launcher  and  Missile 

Status  Data  Base. 

5.  Operations  Module  Performs:  The  Launcher  and  Missile 

Status  Display  module  will 
display  the  information 
contained  in  the  Launcher 
and  Missile  status  Data 

Base  when  prompted  by  the 
Display  module. 


1.  Module  Name:  ENVIRONMENTAL  DISPLAY,  NUMBER  4.3 

2.  Module  Purpose:  To  access  the  Environmental  Data  Base 

and  provide  a  display  of  the  informa¬ 
tion  contained  in  that  data  base. 

3.  Subordinate  Modules:  None 

4.  objects  Used  by  the  Module:  Informatipn  contained  in 

th9  Environmental  Data 
Base. 

5.  Operations  Module  Performs:  The  Environments  Display 

module  will  display  the 
information  contained  in 
the  Environmental  Data  Base 
when  prompted  by  the 
Display  module. 
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1.  Module  Name:  ENGAGEMENT  DISPLAY ,  NUMBER  4.4 

2.  Module  Eurpose:  To  graphically  display  the  flight  path 

cf  missiles  that  are  to  be  flown 
against  a  set  target.  Threat  data  on 
the  target  will  alsp  be  displayed.  The 
engage  sent  play  will  have  the  capa¬ 
bility  to  Be  superimposed  ever  the 
general  track  display. 

3.  Subordinate  Modules:  Threat  pisplay  (4.4.1) 

Automatic  Engagement  (4.4.2) 

Manual  Engagement  (4.4.3) 

4.  Objects  Used  by  the  Module:  Threat  Data  Base  informa¬ 

tion. 

Engagement  Plan  Data  Base 
information. 

Manual  inputs  for  an 

engagement  plan. 

5.  Operations  Module  Performs:  The  Engagement  Display 

module  calls  upon  subordi¬ 
nate  modules  to  provide  the 
operator  a  display  of  the 
computer  generated  engage¬ 
ment  plan  constructed  by 
the  operator.  In  both 

cases,  the  threat  data 

?ertinent  to  the  displayed 
arget  can  also  be  shown. 


93 


Module  Name  :  THBEAT  DISPLAY#  NUMBER  4.4.1 


Module 


PiiTDose*  To  access  the  Threat  Data  .  Base  and 
purpose.  display  of  the  infer nation 

contained  in  that  data  base. 


Subordinate  Modules:  None 
Otiects  Used  by  the  Module: 

Operations  Hcdule  Performs: 


The  information  contained 
in  the  Threat  Data  Base. 

The  Threat  Display,  module 
will  display  the  informa¬ 
tion  contained  in  the 
Threat  Data  Base  when 

Eroapted  by  the  Engagement 
is  play  module. 


Hcdule  Base:  AUTOMATIC  ENGAGEMENT  DISPLAY,  NUMBER  4.4.2 

Module  purpose:  To  graphically  £ispla j Jhe^engagement 

the 


Hcduls  Porpos.:  lo^ra^icslly  «*g!Z.y»b 

Engagement  module  and  stored  in  the 
Engagement  Plan  Data  Base. 

Subordinate  Modules:  Graphics  Display  (4.4.2.  1) 

Objects  Used  by  the  Module:  g.^t^iiaS4  Data 

Base . 

Operations  sodole  Perfor.s: 


tion  of  the  enqa gemint  plan 
as  contained  m  the 

Engagement  Plan  Data  Ease. 
All  missile  trajectories 
and  waypoints  will  be 

depicted  with  associated 
missile  fire  times^  and 
arrive  over  the  target 
time.  The.  uncertainly 
ellipses  will  also  be 

generated  along  with  the 
probability  of  acquisition 
of  the  target. 


.  A.  %  -  + J. 


Module  Mane:  GRAPHICS  DISPLAY,  NUMBER  4.4.2.  1 

Module  Purpose:  To  provide  graphics  capabilities  to  the 

Auxomatic  Engagement  Display  module  and 
the  Manual  Engagement  Display  module. 

Subordinate  Modules:  None 

Objects  Used  by  the  Module:  Engagement  Plan  Data  Base 

information. 

Manually  input  engagement 
plan. 

Operations  Module  Performs:  The  Graphics  Display  module 

§ro video  the  graphics  capa- 
ilities  necessary  to  the 
Automatic  Manual  Engagement 
Display  module  to  accu¬ 
rately  oortray  their  aiven 
engagement  plans. 


Module  Name:  MANUAL  ENGAGEMENT  DISPLAY,  NUMBER  4.4.3 

Module  Purpose:  To  provide  the  operator  the  capability 

to  manually  input  an  engagement  plan 
for  attacking  a  given  target. 

Subordinate  Modules:  G raphics  Di splay  (4.4. 2.1) 

Objects  Used  by  the  Module:  Information  contained  in 

the  Threat  Data  Base. 

Operations  Module  Performs:  The  Manual  Engagement 

Display  module  allows  the 
operator  to  manually  input 
his  own  engagement  plan  for 
a  given  target.  Once  this 
information  is  graphically 
input  to  the  display,  it 
can  be  transferred  to  the 
Engagement  Plan  Data  Base 
where  it  can  be  programmed 
to  the  missiles  like  an 
automatically  generated 
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1. 

2. 


Module  Name:  SHIP  PARAMETERS  DISPLAY,  NUMBER  4.5 


Module  Purpose: 


To  access  the  Ship  Parameter  Data  Base 
and  provide  a  display  of  the  informa¬ 
tion  c  cntamed  in  that  data  base. 


3. 

4. 


5. 


Subordinate  Modules:  None 
Objects  used  by  the  Module: 

Operations  Module  Performs: 


Information 
the  Ship 
Base . 


contained  in 
Parameter  Data 


The  Ship  Parameter  Display 
module  will  display  the 
information  contained  in 
the  Ship  Parameter  Data 
Base  when  prompted  by  the 
Display  module. 


1. 

2. 


3. 

4. 

5. 


Module  Name:  TRACK  DISPLAY,  NUMBER  4.6 


Module  Eurpose: 


and 

all 

data 


Subordinate  Modules:  None 
Objects  Used  by  the  Module: 

Operations  Mcdule  Performs: 


Information  contained  in 
the  Track.  Data  Base. 


The  Track.  Display  mcdule 
will  continuously  .display 
all  tracks  maintained  in 
the  Track  Data  Base.  These 
tracks  will  be  constantly 
updated  as  the  Track  Data 
Base  is  updated.  The 

symbology  ana  method  pres¬ 
entation  of  the  tracks 
should  closely  coincide 
with  NTDS  displays. 
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SYSTEM  DESIGH  USIHG  ADA 


package  OPDATE  is 
type  DEE  IAONCRERS  ; 
type  S1XSPEBD; 

LAO  HBB  :  integer  range  1..NER  LAO 
CAN  NBB  :  integer  range  1..7;  ~ 

MISS  type  :  integer  range  1..7; 

LAO  INHIEIT  :  boolean; 

COO  BSE  ;  integer  range  0.  .359: 

SPEED  :  integer  range  O..MAXSPEED; 
tvce  LATITODE  Is  record 

DEGBEES  :  integer  range  -90.. 90; 
HINOTES  :  integer  range  O..60; 
SECCNCS  :  integer  range  0..60; 
end  record: 

type  LCHGITODE  is  record 

DEGBEES  :  integer  range  -180.. 
HINOTES  :  integer  range  0..60; 
SECCNCS  :  integer  range  0..60; 
end  record; 


wind  SPEED  i  integer  range 


:_LA0NCHEBS; 


-180..  180  ; 
0. .60; 

0. .60; 


359; 


PBECIPITATION 
HOSTILE  NAME 


boclean; 
tring(1. .  12)  ; 


UVtf  Bauu  «  9  \  •  I  ^  I 

SHIP  CLASS  :  string  (1 .  .9)  : 
NATIONALITY  :  string (1 . .1  $)  ; 
weapcns  :  string  (1  .ISO)  : 

ECH  EQOIPMENT  :  string  (1.. 50 


ECH  EQOIPMENT  :  string  (1 .  .5  .  . 
ENGAGEMENT  METHOD  :  string{1..5 
task  LAONCHEB  MISSILE  STATOS  is 
entry  OPDATE  LAO  (LAUNCHER 
CANNISTER  EO HE EE  :  in  C 


--••i  -  -  —  —  —  .wn.'S  N0MBEB  .  ...  ...  ....  f 

CANNISTER  H0HEEE  :  in  C1N  NBB; 

MISSILE  tf pe  ;  in  MISS  type; 

LAONCHEB  INHIBIT  :  in  rAO  INHIBIT)  ; 
end  LAONCHEB- HIS  SHE  STATOS; 
task  SHIP  PAH  A  MET  EF  Is 

entry  OPDATE  COOBSE(SHIP  COOBSE  :  in  COORSE)  ; 
entry  OPDATE"SPEID(SHIP  SPEED  ;  in  SPEED)  ; 
entry  OPDATB"LATHODE(S’BlP  LATITODE  ;  in  LATITODE): 
entry  OPDATE"LONGIT0DE  ( SHIP  LONGITODE  :  in  LONGITODE) 
end  SHIP  PARAMETER; 
task  ENVIRONMENT  is 

entry  OPDATE  VISIBILITY  (VIS  ;  in  VISIBILITY)  ; 
entry  OPDATE“SEA  STATE  ( SEA  ;  in  SEA  STATE): 
entry  0PDATE~WIND  DIR  (W INDDIR  ;  in  HIND  DIRECTION)  ; 
entry  OPDATB"iIND  SPEED  (WINDSPD  :  in  WIHD  SPEED)  ; 
entry  OPDATB”REL  HOH  (RELHOM  :  in  RELATIVE~H0MIDITY)  ; 
entry  OPDATE  TEHIERA TORE  (TEMP  ;  in  TEMPERHORE)  ; 
entry  OPDATE  BAR  PRESS ( EARPRESS  ;  in 
BAECMETHIC”PBB3S0BE)  ; 

entry  0PDATB"PRECIP(PRECIP  :  in  PRECIPITATION); 
end  ENVIRONMENT; 
task  THREAT  is 

entry  ADD  (HOSTILE  ;  in  HOSTILE  NAME; 

NATION  :  in  NATIONALITY; 


LAO_NBR; 


entr 


in  PRECIPITATION) 


* 


L£_NAME; 
t  HOSTILEJiAME; 

HOSTILE.NAME; 


ia  HOSTILE_N  AME; 

5  :  in  EOSTIL E_NAME; 


in  LAU_NB  R ; 


in  COORSE) 
i  COORSE 


SHIP  :  in  SHIP  CLASS; 

REPS  :  in  WEAPONS: 

ECH  I  in  ECH  EQUIPM ENT ; 

HETHCD  ;  in  ENGAGEMENT  METHOD); 
entry  DELETE  (HOSTILE  :  in  HOSTILE  NAME; 

NATION  S  in  NATIONALITY)  ; 
entry  UPDATE  CLASS  JHOSTILE  :  in  HOSTILE  NAME; 

NATION  :  lS  NATIONALITY; 

SHIP  ;  in  SHIP  CLASS): 

entry  UPDATE  WEPSJHOSTILE  :  in  HOSTILE  NAME; 

NATION  !  in  NATIONALITY; 

HEPS  *  In  HE1EONS)  * 

entry  UPDATE  ECH  (HOSTILE  :  in  HOSTILE  NAME; 

NATION  S  in  NATIONALITY; 

ECH  :  in  ECH  EQUIPMENT) ; 
entry  UPDATE  METHOD (HOSTILE  t  in  HOSTILE  NAME; 

NATION  ;  iS  NATIONALITY: 

METHOD  :  in  ENGAGEMENT  METHOD); 
end  THREAT ; 
end  UPDATE: 

package  body  UPDATE  is 

task  body  LAUNCHER  MISSILE  STATUS  is 
begin  ” 

accent  UPDATE  LAU  (LAUNCHER  NUMBER  :  in  LAU  NBR; 
CANBISTER  NUMBER  :  in  CAN  NBR; 

MISSILE  type  :  in  MISS  type; 
l a onc her _ inhibit  :  in  Iau  inhibit)  do 
--  insert  additional  body  of  UPDATE  LAU 
end  UPDATE  LAU; 
end  LAUNCHER“HISSILE  STATUS; 
task  body  SHIP  PARAMETER  is 
begin 

accept  UPDATE  COORSE  (SHIP  COURSE  :  in  COURSE)  do 
--  insert  additional  body"of  UPDATE  COURSE 
end  UPDATE  COURSE; 

accent  UPDATE  SPEIDISEIP  SPEED  s  in  SPEED)  do 
--  insert  additional  body  of  UPDATE  SPEED 
end  UPDATE  SPEED; 

accent  UEOITE  LATITUDE  (SHIP  LATITUDE  :  in  LATITUDE)  do 

—  insert  additional  body  cf  UPDATE  LATITUDE 
end  UPDATE  LATITUDE; 

accept  UPDATE_LONGITUDE  (SHIP_LONGITUDE  :  in  LONGITUDE) 

--insert  additional  body  of  UPDATE  LONGITUDE 
end  UPDATE  LONGITUDE; 

--  insert  additional  body  of  task  SHIP  PARAMETER 
end  SHIP  PARAMETER; 
task  body  ENVIRONMENT  is 
begin 

accent  UPDATE  VISIBILITY  (VIS  :  in  VISIBILITY)  do 

—  insert  additional  body  of  UPDATE  VISIBILITY 
end  UPDATE  VISIBILITY; 

accept  UPDATE  SEA  ST  ATE  (SEA  :  in  SEA  STATE)  do 

—  insert  addlticlal  body  cf  UPDATE_SEA  STATE 
end  UPDATE  SEA  STATE; 

accept  UPDATE  WIND  DlR  ( NINDDIR  :  in  WIND  DIRECTION)  do 

—  insert  additional  body  of  UPDATE  WIND  DIR 

end  UPDATE  WIND  DIB;  “ 

accent  UPDATE  WIND  SPEED (WINDSPD  :  in  WIND  SPEED)  do 
--  insert  addltionll  body  of  UPDATE_WIND_SPEED 
end  UPDATE  RIND  SPEED; 

accent  UPDATE  Hit  HUM(HUH  :  in  RELATIVE  HUMIDITY)  dc 
--  insert  addlticlal  Body  cf  UPDATE  REL  HUH 
end  UPDATE  BEL  HUH:  , 

accent  UPDATE  TEHPERATU  BE  (TEMP  :  in  TEMPERATURE)  do 
--  insert  additional  body  cf  UPDATE  TEMPERATURE 
end  UPDATE  TEMPERATURE: 
accent  UPDATE  BAR  PRESS (BARPRESS  :  in 
BAf CHETRIC  PRESSURE)  do 


:  in  VISIBILITY)  do 
UPDATS_VISIBILITY 

in  SEA  STATE)  do 
UPDATE  SEA  STATE 


STATE 
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--  insert  additional  body  of  UPDATE  BAH  PRESS 
and  UPDATE  BAB  PRESS; 

accaot  UPDATE  PRECIP  (PR  ECIP  :  in  PRECIPITATION) 
—  insert  additional  body  of  UPDATE  PRECIP 
end  UPDATE  PRECIP: 

—  insert  additional  body  of  cask  ENV IRONMENT 
end  ENVIRONMENT: 

task  body  THREAT  is 
begin 

accent  ADD  (HOSTILE  :  in  HOSTILE  NAME; 

NATION  :  in  NATIONALITY; 

SHIP  :  in  SHIP  CLASS; 

HEPS  :  in  WEAPONS: 

ECH  :  in  ECH  EQUIPS  ENT; 

HZTHOD  :  in  ENGAGEMENT  METHOD)  do 

—  insert  additional  body  of  ADD 
end  ADD; 

accept  DELETE  (HOSTILE  :  in  HOSTILE  NAME; 
NATION  :  in  NATIONALITY)  do 

—  insert  additional  body  of  DELETE 
end  DELETE; 

accent  UPDATE  CLASS(HOSTILE  :  in  HOSTILE  NAME 


DELETE 


NATION  :  in~  NATIONALITY; 

SHIP  :  in  SHIP  CLASS)  do 
—  insert  additional  body  of  UPDATE 
end  UPDATE  CLASS; 


HOSTILE_NA  ME ; 


CLASS 


accent  UPDATE  HEPS (HO  STILE  : 
NATION  ;  in" NATIONALITY; 


do 

body  of 


HEPS  :  in  WEAPONS)  do 
—  insert  additional  body  i 
end  UPDATE  HEPS; 
accept  UPDATE  ECH  (HO  STILE 
NATION  :  in" NATIONALITY; 


in  HOSTILE_NAME; 

UP  DATE_HEPS 
n  HOSTILE  NAME; 


ECH  :  in  ECH  EQUIPMENT)  do 
--  insert  addifional  body  of  UP  DATE_ECH 


--  insert  additional  bod 
end  UPDATE  ECH; 
accept  UPDATE  METHOD (HOS 
NATION  :  in" NATION ALIT 
METHOD  :  in  ENGAGEMENT 
-•  insert  additional  bod 


(HOSTILE 

ALITY: 


-•  insert  additional  bodf  of  UPDATE  H 
end  UPDATE  ECH; 

—  insert  ADDITION  body  of  task  THREAT 
end  THREAT; 
begin 

—  insert  additional  body  of  package  UPDATE 
end  UPDATE; 

package  AUTC  ENGAGEHENT  is 
type  HER  LAUNCHERS; 

LAO  NBR  :  integer  range  1..NER  LAUNCHERS; 
CAN  NBR  :  integer  range  1..4; 

MISSILE  type  :  integer  range  1..7; 

LAU  INHIBIT  :  boolean; 

HOSTILE  NAME  :  str ing ( 1 . .  12)  ; 


THREAT 


n  HOSTI LE_N  AHE 
do 

ATE  METHOD 


LAU  INHIBIT 
HOSTILE  NAME  :  stringfl. .  12)  ; 
NATIONALITY  ;  str ingti . ,  1 0)  ; 
GAGEMENT  METHOD  ;  String  (1..  50) 
procedure  AUTO  ENGAGE  (LAUNCHER 
CAHNISTEB  NBR  :  in  CAN  NBR;  “ 


bool< 

str: 


NATIONALITY  ;  string 
ENGAGEMENT  METHOD  S 


CAHNISTEB  NBR  :  In  CAN  NBR;  ~ 
HISS  type";  in  HISSILE”type ; 

HOSTI ir  :  in  HOSTILE  .HEME; 

NATION  :  in  NATIONALITY; 

METHOD  :  oat  ENGAGEH  ENT  METHOD) ; 


in  LAU_NBR; 


orocedure  PROB  ACQUISITIONlHETHOD 


ENGAGEHENT  METHOD)  ; 
procedure  UNCERTAIN!  TY  ELLIPSE (M 
ENGAGEMENT  METHOD)  ;  " 
end  AUTO  ENGAGEMENT: 
package  body  AUTO  ENGAGEHENT  is 
procedure  AUTO  ENGAGE  f  LAU  NCHER.NBR 
CANNISTER  NBR  :  in  CAN  NBR; 


Y_ ELLIPSE (METHOD  ;  in  out 


:an_nbr; 


do 
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HISS  type  i  in  HISSILE  type; 

HOSTILE  ;  in  HOSTILE  NIME; 

NATION  :  in  NATIONALITY; 

METHOD  :  out  ENGAGEMENT  METHOD)  is 
beain 

--  insert  additional  body  of  procedure  AUTO  ENGAGE 
end  ADTC  ENGAGE; 

procedure  PROB  iCQUISITIO  N  (METHOD  :  in  out 
ENGAGEMENT^ METHOD)  is 
begin 

--  insert  additional  body  of  procedure  PROB  ACQUISITION 
end  PBCE  ACQUISITION: 

orccedure  UNCERTAI NIT?  EL  LIP SE (METHOD  :  in  cut 
'  ENGAGEMENT_METHOD)  IS 

--insert  additional  body  of  procedure 
—  UNCERTAINIT Y  ELLIPSE 
end  UNCERTAI NITY  ELLIPSE; 
beqin 

—  insert  additional  body  of  package  AUTO  ENGAGEMENT 
end  AUTO  ENGAGEMENT: 
package  MANUAL  ENGAGEMENT  is 
tvce  NER  LAUNCHERS; 

LAO  NBE  :  integer  range  1..NBR  LAUNCHERS; 

CAN  NBR  :  integer  range  1..4;  “ 

MISSILE  type  :  integer  range  1..7; 

LAU  INHIBIT  :  boolean; 


ENGAGEMENT  METHOD  :  sirinq(1..50 
procedure  MANUAL  ENG  AGE  (LAUNCH 
CANNISTER  NBR  T  in  CAN  NBR; 

HISS  type  :  in  HISSILE“type; 
METHOD  :  out  ENGAGEMENT  METHOD)  ; 
end  MANUAL  ENGAGEMENT; 
packaqe  body  MANUAL  ENGAGEMENT  is 
Drocedure  manual  Engage (L AONCHER  nbb 

C  ANNTST'ER  NBR  T  in  CAN  NBR; 


_NBR  ;  in  LAU_NBR; 


in  LAU.NBB; 


CANNISTER  NBB  T  in  CAN  NBR; 

HISS  tyce'j  in  MISSILE  type; 

METHOD  :  out  ENGAGEMENT  METHOD)  is 
begin  ” 

--  Insert  additional  body  of  procedure  MANUAL  ENGAGE 
end  MANUAL_ENG  AGE ; 
begin 

—  insert  additional  body  of  package  MANUAL  ENGAGEMENT 
end  MANUAL  ENGAGEMENT; 
package  DISPLAY  is 
tvce  MENU  type; 
tyoe  HAYS  FEED ; 

VISIBILITY  :  integer  range  0..30; 

SEA  STATE  :  integer  range  0..10; 

HIND  DIRECTION  :  Integer  range  0..359  ; 

NINE  SPEED  :  integer  range  0..100: 

RELATIVE  HUMIDITY  :  integer  range  0..100; 

TEMPERATURE  :  integer  range  -100..  130: 

BAROMETRIC  PRESSURE  :  integer  range  900.. 1100; 
type  PRECIPITATION  is  (YES.  NO)  ; 

COURSE  :  integer  range  0.  .359; 

SPEED  :  integer  range  0. .  MAXSPEED; 
type  LATITUDE  is  record 

DEGREES  :  integer  range  -90. .90; 

MINUTES  :  integer  range  0..60; 

SECONDS  :  integer  range  0..60; 
end  record: 

type  LONGITUDE, is  record  _  _ 

DEGREES  :  integer  range  -180..  1  80; 

MINUTES  :  integer  range  Q. .  60; 

SECONDS  :  integer  range  0.  .60; 
end  record; 

HOSTILE  NAME  :  Str  ioq  ( 1 .  .  12)  ; 

NATIONALITY  :  strlng(1 . .  1  0)  ; 
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shii  cuss 

HEAPONS  : 
ECH  EOUIPM 


string  <1.  .9) 


NS  :  string  (1  ..50)  : 
QUIPMENT  :  string  (1.  .50) ; 
EMENT  HETHOD  :  string(1.. 

.•■iu  a  i  i  -  _____  »  '  j 


!T HOD  :  string(1..50)  ; 

:  integer  range  100.. 3 19 9; 
integer  range  1..7; 

:  integer  range  0..1; 


ENGAGEMENT  HETHOD  :  st rin g ( 1 . . 50)  ; 

TRACK  NOHBER  :  integer  range  100.. 3 19 9; 

TRACK  type  :  integer  range  1..7; 

VESSEL  Class  :  integer  range  0..1; 
tyre  HAXranga; 

HOSrange  :  integer  range  0.. HAXranga; 

BEARING  :  integer  range  0  ..359; 

HOSTILE  LAT  :  LATITUDE: 

HOSTILE  LCNG  :  LONGITUDE; 

BNGAGBHENT  PLAN  :  string  ( 1 ..  50)  ; 
task  HINU  DISPLAT  is 

entry  ACCESS  HENU  (HENU  :  out  MEN0_type)  ; 
end  HENU  DISPLAY; 
task  LAUNCHER  MISSILE  STATUS  is 

entry  ACCESS  LH (LAUNCHE R  NBR  :  out  LAU  NB R; 
CANNISTER  NBR  :  out  CAN  NBR; 

HISS  type":  out  HI SSI LE“ type; 

INHIBIT  :  out  LAU  INHIBIT); 
end  LAUNCHER  MISSILE  STATUS; 
task  ENVIRONMENT  Is 

entry  ACCESS  ENV  (VIS  :  out  VISIBILITY; 

SEA  s  out  SEA  STATE; 

HINCDIR  :  0Ut”HIND  DIRECTION; 

BINDS PD  :  out  NIND"SPEBD; 

RELHUH  :  out  RELATIVE  HUMIDITY; 

TEHP  :  out  TEHEERATURl: 

BARPRESS  :  out  BAROMETRIC  PRESSURE; 

ERECIF  :  out  PRECIPITATION); 
end  ENVIRONMENT; 
task  SHIP  PARAMETER  is 

entry  ACCESS  SP(SHIP  COURSE  :  out  COURSE; 
SHIP  SPEED":  out  SNEED: 

SHIP  LATITUDE  :  out  LATITUDE: 

SHIP  LONGITUDE  t  out  LONGITUDE)  ; 
end  SHIP" PARAMETER; 
task  TRACK  is 

entry  ACCESS  TR (TRACK  HUM  :  out  TRACK  NUMBER; 
TRACK  TYP  :  out  TRACK  type ; 

CLASS  :  out  VESSEL  CLNSS; 

HNG  :  out  HOSr angel 
BRNG  :  out  BEARING: 

HOST  LAT  :  out  HOSTILE  LAT: 

HOST  LONG  :  out  HOSTILE  LONG)  ; 


out  COURSE; 


HOSTILE_NAME; 


BRNG  :  out  BEARING: 

HOST  LAT  :  out  HOSTILE  LAT: 

HOST  LONG  :  out  HOSTILE  LONG)  ; 
end  TRACK; 
task  THREAT  is 

entry  ACCESS  TH  (HOSTILE  s  out  HOSTILE  NAME; 
NATION  :  out  NATIONALITY; 

SHIP  :  out  SHIP  CLASS; 

BEPS  :  out  BEAFENS: 

ECH  :  out  ECH  EQUIPMENT; 

METHOD  :  out  ENGAGEMENT  METHOD)  ; 
end  THREAT; 

task  ENGAGEMENT  PLAN  is 

entry  ACCESS  EN  (TRACK  NUM  :  out  TRACK  NUMBER; 
PLAN  :  out  "ENGAGEMENT  PLAN)  ; 


entry  ACCESS  EN  (TRACK  NUM  :  out  TRACK  N 
PLAN  :  out  "ENGAGEMENT. PLAN)  ; 
end  ENGAGEMENT  PL  AH: 
package  ENGAGEMENT  DISPLAY  is 

procedure  AUTO  DlSPLAllTRACK  NUM  :  in  o 
PLAI  :  in  ouf  ENGAGEMENT  PlAN: 

HOSTILE  :  In  cut  HOSTIlE  NAME; 
1ATION  :  in  out  NATIONALITY; 

SHIP  :  in  out  SHIP  CLASS; 

HEPS  : ,  in  out  HEAPONS: 

ECH  :  in  out  ECH  EQUIPMENT; 

HETHOD  :  in  out  ENGAGEMENT  METHOD); 
procedure  HANUAL  DISPLA I (TRACK  NUM  :  in 


TRACK  NUMBER 
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TRACK  NUMBER; 

PLAN  :  in  out  ENGAGER  ENT  PLAN; 

HOSTILE  :  in  out  HOSTILE  NAME; 

NATION  ;  in  out  NATIONALITY; 

HEPS  :  in  out  HEAPONS: 

ECM  ;  in  out  ECM  EQUIPMENT; 

METHOD  ;  In  out  ENGAGEMENT  METHOD)  ; 
crocedure  GRAPHICS; 
and  ENGAGEMENT  DISPLAY; 
and  DISPLAY; 
package  fcodv  DISPLAY  Is 
task  body' MENU  DISPLAY  is 
begin 

accent  ACCESS  MENU  (MENU  :  out  MENU  type) 
-  -  insert  additional  body  of  ACCESS  MENU 
end  ACCESS  MENU; 

--  insert  additional  body  of  task  MENU  DIS 
end  MENU  DISPLAY; 

task  body  LAUNCHES  MISSILE  STATUS  is 
begin 

accent  ACCESS  LM  (LAUNCHER  NBR  :  cut  LAU 
CANNISTER_NFR  :  out  CAN“NBR; 

MISS  type-:  out  MlSSILETtype; 


MENU  DISPLAY 


LAU_NBR; 


miss  rype  :  out  missile  type; 

INHIBIT  :  OUt  LAO  INHIBIT/  do 
--  insert  additicnal  body  of  ACCESS  LM 
end  ACCESS  LM; 

--  insert  additional  body  of  task  LAUNCHER  HISS  I 
end  LAUNCHER  MISSILE  STATUS; 
task  body  ENVIRONMENT  is 
begin 

accent  ACCESS  ENVJVIS  :  out  VISIBILITY; 

SEA  :  OUt  SEA  STATE; 

HINDDIR  :  out  HIND  DIRECTION; 

HINCSPD  :  out  HIND  SPEED; 

RELHUH  :  out  RELATIVE  HUMIDITY; 

TEMP  :  OUt  TEMPERATURE; 

BARPRESS  :  out  BAROMETRIC  PRESSURE; 

PRECIP  ;  out  PBECIPIT  ATIOT5T)  do 
•  --  insert  additicnal  body  of  ACCESS  ENV 
end  ACCESS  EN; 

—  insert  additional  body  of  task  ENVIRONMENT 
end  ENVIRONMENT; 

task  body  SHIP  PARAMETER  is 
beqin 

accept  ACCESS  S P  (SHIP  COURSE  :  out  COURSE; 

SHIP  SPEED  T  out  SPEED; 

SHIP  LATITUDE  :  out  LATITUDE; 

SHIPILONGITUDE  :  cut  LONGITUDE)  do 
--  insert  additicnal  body  of  ACCESS  SP 
end  ACCESS  SP; 

—  insert  additional  body  of  task  SHIP  PARAMETER 
end  SHIP  PARAMETER; 

task  body  TRACK  Is 
begin 


MISSILE  STATUS 


acce 


out  TRACK_NU  MBER ; 


RNG  :  out  HOSrange; 

BBNG  :  out  BEARING; 

HOST  LAT  J  OUt  HOSTILE  LAT: 

HOST  LONG  :  out  HOSTILE  LONG)  do 
—  insert  additicnal  body”cf  ACCESS  TR 
end  ACCESS  TR; 

—  insert  additional  body  of  task  TRACK 

end  TRACK; 

task  body  THREAT  is 

begin 

accent  ACCESS  TH  (HOSTILE  S  out  HOSTILE  NAME; 
NATION  :  OUl  NATIONALITY; 


SHIE  :  out  SHIE  CLASS; 

HEPS  ;  out  HEAECNS: 

ECU  :  out  ECU  EQUIPMENT; 

METHOD  ;  out  ENGAGEMENT  METHOD)  do 
--  insert  additional  body~of  ACCESS  TH 
end  ACCESS  TH: 

--  insert  additional  body  of  task  THREAT 
end  THREAT: 

task  body  ENGAGEMENT  PLAN  is 
begin 

accept  ACCESS  BN  (TRACK  NOM  :  out  TRACK  NUMBER; 

PLAN  :  out  ENGAGEMENT  PLAN)  do 
--  insert  additional  body  cf  ACCESS  EN 
epd  ACCESS  EN: 

—  insert  additional  body  of  task  ENGAGEMENT  PLAN 
end  ENGAGEMENT  PLAN; 
package  body  ENGAGEMENT  DISPLAT  is 

crocedure  AUTO  DISPL AT ( TRACK  NUM  :  in  out  TRACK  NUMBER 
‘  PLAN  :  in  ouT  ENGAGEMENT  PLAN; 


'  PLAN  :  in  ouT  ENGAGEMENT  PLAN; 

HOSTILE  :  in  out  HOSTILE"NAME; 

NATION  :  in  out  NATIONALITY; 

SHIE  :  in  out  SHIP  CLASS; 

HEPS  :  In  out  HEAPONS: 

ECM  :  in  out  ECH  EQUIPMENT; 

METHOD  :  in  out  ENGAGEMENT  METHOD)  is 
begin 

—  insert  additional  body  cf  procedure  AUTO  DISPLAY 
end  AUTC  DISELAT; 

procedure  MANUAL  DISPLA Y (TRACK  NUM  :  in  out 
TRACK  NUMBER;  ~ 

PLAN  :  in  out  ENGAGEMENT  PLAN; 

HOSTILE  :  in  out  HOSTILE“NAME; 

NATION  :  in  out  NATIONALITY; 

HEPS  :  in  out  HEAPONS: 

ECH  :  in  out  ECH  EQUIPMENT; 

METHOD  :  in  out  ENGAGEMENT  METHOD)  is 


METHOD  :  in  out  EN< 


I_  METHOD)  is 


— ^insert  additional  body  of  procedure  MANUAL  DISPLAY 
end  MANUAL  DISPLAY; 
procedure  GRAPHICS  is 


GRAPHICS  is 


begin 

--  Insert  additicnal  body  of  procedure  GRAPHICS 
end  GRAFHICS; 

--insert  additional  body  of  package  ENGAGEMENT  DISPLAY 
end  ENGAGEMENT  DISELAY; 
beg+n 

—  insert  additional  bcdy  of  package  DISPLAY 
end  DISELAY: 

package  DATA  BASE  MANAGER  is 
package  LH~STATUS  MANAGER  is 
type  NBRILAUNCHERS; 

L«u  NEB  :  integer  range  1..NBR  LAUNCHERS; 

CAN  NBR  :  Integer  range  1..4;  ~ 

MISS  tyoe  :  integer  range  1..7; 

LIU  INHIBIT  :  boolean: 

task  LAUNCHER  MISSILE  STATUS  is 

entry  UPDATE  LAU  (LAUNCBER  :  in  LAU  NBR; 

CANNISTER  7  in  CAN  NBR; 

MISSILE  :  In  HISS  Type; 

LAUNCHER  INHIBIT  1  in  LAU  INHIBIT)  ; 
entry  ACCESS  LM( LAUNCHER  :  oUt  LAU  NBR; 

CANNISTER  1  out  C  IN  NBR; 

MISSILE  :  out  MISS_Type: 

LAUNCHER  INHIBIT  :  Ou€  LAU  INHIBIT)  ; 
end  LAUNCHER"  HI  SSI  LE  STATUS; 
end  LH  STATUS  MANAGER; 
package  SE  MANAGER  is 
tyoe  MAZSPEED; 
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in  COURSE; 


COURSE; 


CCUfiSE  ;  integer  range  0..  359; 

SPEED  :  integer  range  0..MAXSPEED; 
type  IATHUDE  is  record 

DEGREES  ;  integer  range  -90.. 90  ; 

MINUTES  :  integer  range  0..60; 

SECONDS  :  integer  range  0..S0; 

end  record: 

type  LONGITUDE  is  record 

DEGREES  :  integer  range  -180.. 180; 

MINUTES  :  integer  range  0..60; 

SECONDS  :  integer  range  0..60; 

end  record; 

task  SHIP  PARAMETER  is 

entry  UPDATE  SPfSHIP  COURSE  :  in  COURSE; 
SHIP  SPEED”:  m  SPEED; 

SHIP” L ATI T ODE  :  in  LATITUDE; 

SHIP” LONGITUDE  :  in  LONGITUDE)  : 
entry  ACCESS  SP(SHIP  COURSE  :  out  COURSE; 
SHIP  SPEED”:  out  SPEED: 

SHIP'LATITUDE  :  out  LATITUDE: 

SHIP” LONGITUDE  :  out  LONGITUDE) ; 
end  SHIP  "PARAMETER; 
end  SP  MANAGER: 

package  ENVIRONMENT  HANAGER  is 

VISIBILITY  :  integer  range  0..30; 

SEA  STATE  :  integer  range  0..10: 

HIND  DIRECTION  :  integer  range  0..359; 

HIND  SPEED  :  integer  range  0..100; 

RELATIVE  HU HIDIT Y  ■ :  integer  range  0..100; 
TEMPERATURE  :  integer  range  -100.. 130: 
BAROMETRIC  PRESSURE  :  integer  range  900..  1000; 
PRECIPITATION  :  boolean; 
task  ENVIRONMENT  is 

entry  UPDATE  ENV(VIS  :  in  VISIBILITY; 

SEA  :  in  SEA  STATE: 

WIND&IR  :  in  WIND.DIRBCTION ; 

WINDSPD  :  In  WIND  SPEED; 

RELHUM  :  in  RELATIVE. HUMIDITY; 

TEMP  :  in  T?HPERATURE: 

BARPRESS  :  In  BAROMETRIC  PRESSURE; 

PRECIP  :  in  PRECIPITATION ; 
entry  ACCESS  ENVfVIS  :  out  VISIBILITY; 

SEA  :  out  SEA  STATE: 

WINDDIR  :  out  WIND  DIRECTION; 

WINDSPD  :  out  WIN  E”SPEED; 

RELHUM  :  out  RELATIVE  HUMIDITY; 

TEMP  :  out  TEMPERATURE: 

BARPRESS  :  cut  BAROMETRIC  PRESSURE; 
PRECIP  :  out  PRECIPITATION)  ; 
end  ENVIRONMENT: 
end  ENVIRONMENT  MANAGER: 
package  THREAT  HANAGER  is 

HOSTILE  NAME”:  string ( 1 ..  1 2)  ; 

NATIONALITY  :  string]! .  .  10)  ; 

SHIP  CLASS  :  string  (T. .  9)  ; 

WEAPONS  :  string  (1.,  50)  : 

ECH  EQUIPMENT  :  string (1.. 50)  ; 

ENGAGEMENT  METHOD  :  str  ing  (1 .  .50)  ; 
task  THREAT  is 

entry  ACCESS  TH (HOSTILE  :  out  HOSTILE  NAME 
NATION  :  oHt  NATIONALITY; 

SHIP  :  out  SHIP  CLASS; 

HEPS  :  out  WEAPONS: 

ECH  :  out  ECH  EQUIPMENT; 

METHOD  :  out  ENGAGEMENT  METHOD); 
end  THREAT: 
end  THREAT  MANAGER; 
package  TRACK  MANAGER  is 

TRACK  NUMBER  :  integer  range  100.. 3199; 


HOSTILE  NAME 


1  80; 


TRACK  type  ;  integer  range  1..7; 

VESSEI  CLASS  :  inxeger  range  0..1; 
type  HAXrange; 

HcSrange  :  integer  range  0.. HAXrange; 

BEARING  ;  integer  range  0..359; 
type  HOSTILE_LAT  is  record 

DEGREES  T  integer  range  -90..  90  ; 

MINUTES  :  integer  range  0..60; 

SECONDS  :  integer  range  0..60; 
end  record; 

type  HOSTILE  LONG  is  record 

DEGREES  T  integer  range  -180.. 

MINUTES  :  integer  range  0..60; 

SECONDS  :  integer  range  0..60; 
end  record; 
task  TRACK  is 

entry  A D D (T  R ACK  NUH  ;  in  TRACK  NUMBER  ; 

TRACK  Tip  :  in  TRACK  type;  ~ 

CLASS”:  in  VESSEL  CLASS; 

RNG  :  in  HCSrangeT 
BRNG  ;  in  BEARING; 

HOST  LAI  ;  in  HOSTILE  LAT; 

HOST~LONG  J  in  HOSTILE  LONG); 
entry  DELETE  (TRACK  NUM  :"in  TRACK  NUMBER; 

TRACK  TYP  :  in  TRACK  type)  ; 
entry  ACCESS  IR  (TRACK  RUM  :  our  TRACK  NUMBER; 
TRACK  TYP  1  out  TRACK  type; 

CLASS";  out  VESSEL  CLASS; 

RNG  ;  out  HCSrangeT 
BRNG  :  out  EEARING ; 

HCST  LAT  :  out  HOSTILE  LAT; 

HOST"LONG  :  out  HOSTILE  LONG)  ; 
entry  UPDATE  TY (TRACK  NOM":  in  fRACK 
TRACK  TYP  T  in  TRACE  type)  ; 
entry  UPDATE  CL (TRACK  RUB  :  in 
CLASS  :  in  VESSEL  CLASS) 
entry  UPDATE  RN  (TRACK  NUM 
RNG  :  in  HCSrange):" 
entry  UPDATE  BE (TRACK  NUM 
BRNG  :  in  REARING)  ;" 
entry  UPDATE  ^A(TRACK  NUM 
HOST  LAT  S  In  HOSTILE  LAT) 
entryUPDATE  LO (TRACK  NUM  : 

HOST  LONG  ;  in  HOSTILE  LONG); 
end  THACK;- 
end  TRACK  MANAGER: 
packaqe  MENU  MANAGER  is 
type  MENU  type; 
task  MENU  is 

entry  ACCESS  HE  (MENU  TY  :  out  MENU  type) 
end  MEND  ; 
end  MEND  MANAGER: 

package  ENGAGEMENT  PLAN  MANAGER  is 
TRACK  NUMBER  :  I  Integer  range  100. 

ENGAGEMENT  PLAN  :  strin  g  (1 . .  50) 

HOSTILE  NAME  :  Stpinr**  - 
NATIONALITY  :  strinc 


^NUMBER; 
TRACK_NUMB  ER; 
in  TRACK_ NUMBER; 
in  TRACK  NUMBER; 


in 

In 


TRACK_NDMBER; 

TRACK_NUMBER; 


3199 


LnqM  :.12)  ; 
3)  ; 


SHIP  CLASS  :  string!, 

WEAPONS  :  string  (1.. 50)  . 

ECM  EQUIPMENT  :  string ( 1. . 50) ; 

ENGAGEMENT  METHOD  :  str  ing  (1 .  .50)  ; 
task  ENGAGEMENT  PLAN  is 

entry  ACCESS  1NJTRACK  NUM  :  out  TRACK  NUMBER; 
PLAN  :  out  ENGAGEMENT  PLAN; 

HOSTILE  :  out  HOS  TILE”NAME; 

NATION  :  out  NATIONALITY; 

SHIP  :  out  SHIP  CLASS; 

WEPS  :  out  WEAPONS; 

ECM  :  out  ECM  EQUIPMENT; 
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METHOD  :  OUt  ENGAGEMENT  METHOD)  ; 
and  ENGAGEMENT  ELAN: 
end  ENGAGEMENT  PL  AH  MANAGES; 
end  DATA  BASE  MANAGEBT 
package  body  DATA  BASE  MANAGES  is 
package  bcdv  LM  STATUS  MANAGER  is 

task  body  LI0NCHER"MI  SSILE  STATUS  is 
beqin  “ 

accept  UPDATE  LAO  (LAUNCHES  :  in  LAU  NBR ; 
CANNISTEH  :"in  CA N_NBR  ; 


NBR; 


MISSILE  ;  in  MISS  ’Type; 

LAUNCHES  INHIBIT  T  In  LA U  INHIBIT)  do 
--  insert  Sddltional  body  of  UPDATE^ LAO 


SS_LM; 


end  UPDATE  LAU: 

accept  ACCESS  LM  (LAUNCHER  :  out  .n.NBS; 
CANNISTEH  :~OUt  CAN  NBB ; 

MISSILE  :  cut  MISS  Hype ; 

LAUNCHES  INHIBIT  :~Ouf  LAU  IN  3IT)  do 
—  insert  additional  body  of"AC  'SS  LM; 
end  ACCESS  LM: 

end  LAUNCHES- MISSILE  STATUS; 
begin  “  ” 

—  insert  additional  body  of  package  Ln  STATUS  MANAGER 
end  LM  STATUS  MANAGES; 
package  body  5P  MANAGES  is 
task  body  SHIP  PAEAMETE B  is 
begin 

accent  UPDATE  SI  (SHIP  COURSE  :  in  COURSE; 

SHIP  SPEED  T  in  SPEED; 

SHIP  LATITUDE  :  in  LATITUDE; 

SHIFILONGITUDE  :  in  LONGITUDE)  do 
—  insert  additional  body  of  UPDATE  SP 
end  UPDATE  SP; 

accept  ACCESS  SP(SHIP  COURSE  :  out  COURSE; 

SHIP  SPEED  T  out  SPIED; 

SHIP“LATITnDE  :  out  LATITUDE; 

SHIP“LOHG!TUDE  :  out  LONGITUDE)  do 
--  insert  additional  body  of  ACCESS  SP 


--  insert  additional  body  of  ACCESS  SP 
end  ACCESS  SP; 
end  SHIF_PABIHETEB; 

--^insert  additional  body  of  package  SP  MANAGER 
end  SP  MANAGES; 

Dackage  body  ENVIRONMENT  MANAGES  is 
task  body  ENVIRONMENT  is 
begin 

accept  UPDATE  ENV(VIS  :  in  VISIBILITY; 

SEA  :  in  SE1  STATE; 

NINDDIB  :  in  WIND  DIBECTION; 

NINDSPD  :  in  SIND  SPEED; 

BE1HUH  :  in  BELAT1VE  HUMIDITY; 

TEMP  :  in  TEMPERATURE; 

BARPRESS  :  in  BAROMETRIC  PRESSURE; 
PBECIP  :  in  PRECIPITATION)  do 

—  insert  additional  body  of  UPDATE  ENV 
end  UPDATE  BNV: 

accept  ACCESS  EHVJVIS  :  out  VISIBILITY; 
SEA  :  out  Si  A  STATE: 

WINDDIR  :  oUt  HIND  DIBECTION; 

NINDSPD  :  out  V INC  SPEED: 

BBLHUH  :  cut  RELATIVE  HUMIDITY; 

TEMP  :  out  TEMPERATURE; 

BARPRESS  :  OUt  BAROMETRIC  PRESSURE; 
PBECIP  S  out  PRECIPITATION).  do 

—  insert  additional  body  of  ACCESS  ENV 
end  ACCESS  BNV; 

end  ENVIRONMENT; 


beg  | 


nsert  additional  body  of  package  ENVIBONMEN t_man  ages 
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and  ENVIRONMENT  MANAGER: 
packaqe  body  THREAT  MANAGER  is 
task  body  THREAT  is 
begin 

accept  ACCESS  TH  (HOSTILE  :  out  HOSTILE  NAME; 

NATION  :  ouE  NATIONALITY; 

SHIP  :  out  SHIP  CLASS; 

REPS  :  cut  WEAPONS: 

ECM  :  out  ECM  EQUIPMENT; 

METHOD  :  out  ENGAGEMENT  METHOD)  do 
—  insert  additional  body  of”ACCESS  TH 
end  ACCESS  TH; 
end  THREAT;  ~ 
begin 

—  insert  additional  body  of  package  THREAT  MANAGER 
end  THREAT  MANAGER; 
package  bodv  TRACK  MANAGER  is 
task  body  TRACE  is 
begin 

accept  ADD  (T  RACK  NU  M  :  in  TRACK  NUMBER; 

TRACK  TYP  :  in'TRACK  type; 

CLASS” :  in  VESSEL  CLASS; 

RNG  :  in  HOSrangeT 


TRACK  NUMBER; 
do 

DELETE 

out  TRACK  NUMBER 


RNG  :  in  HOSranqe; 

EENG  :  in  EEARING; 

HOST  LAT  I  in  HOSTILE  LAT: 

HCSI~LCNG  :  in  HOSTILE  LONG)  do 

—  insert  additional  bcdy  of  ADD; 
end  ADD: 

accept  DELETE  (TRACK  NDM  :  in  TRACK  NUMBER; 
TRACK  TYP  :  in  TRICK  type)  do 

—  insert  additional  body  of  DELETE 
end  DELETE; 

accept  ACCESS  TR  (TRACK  NUM  :  out  TRACK  NUMBER 
TRACK  TYP  :”out  TRACE  type; 

C LAS'S  :  out  VESSEL  CLASS; 

RNG  :  out  HOSrangeT 
BENG  :  out  BEARING; 

HOST  LAT  :  out  HOSTILE  LAT: 

HOST” ID NG  :  out  HOSTILE  LONG)  do 

—  insert  additional  body'of  ACCESS  TR 
end  ACCESS  TR; 

acceDt  UPDATE  TY(TRACK  NUM  :  in  TRACK  NUMBER 
TRACK  TYP  :”in  T HACK”"' ype)  do 

—  insert  additional  body  of  update  TY 
end  UPDATE  TY; 

accept  UPDATE  CLfTRACK  NDM  :  in  TRACK  NUMBER 
CLASS  :  in  VESSEL  CLASS)  do 

—  insert  additional  body  of  UPDATE  CL 
end  UPDATE  CL; 

accept  UPDATE  RN  (TRACK  NUM  :  in  TRACK  NUMBER 


:cept  UPDATE  RN  (TRACK  NUM  : 
RNG  :  in  HCSr ange)  do 
■  insert  additional  body  of 


TRACK  NUMBER 


TRACK  NUMBER 


UPDATE 


TRACK  NUMBER 


—  insert  additional  body  of  UPDATE  RN 
end  UPDATE  BN; 

accept  UPDATE  BR  (TRACK  NUM  :  in  TRACK  NUMBE 
ERNG  :  in  EEARlN G)  S5 

—  insert  additional  body  of  UPDATE  TR 
end  UPDATE  TE; 

acceDt  UPDATE  LA  (TRACK  NUM  :  in  TRACK  NUMBE 
HOST  LAT  ;  In  HOSTILE  LAT)  do 

—  insert  additional  body  of  UPDATE  LA 
end  UPDATE  LA; 

accept  UPDATE  LO(T  RACK  NUM  :  in  TRACK  NUMBE 
HOST  LONG  :"in  HOSTILE  LONG)  do 
--  insert  additional  body  of  UPDATE  LO 
end  UPDATE  LO; 
end  TRACK; 
begin 

--  insert  additional  body  of  package  TRACK  MANAGER 
end  TRACK  MANAGER; 


IR  (TRACK  NUM  : 
iRlN  gP  <33 
:ional  body  of 

■  A  (TRACK  NUM  : 

HOSTILE  LAT) 
;ional  body  of 


m  TRA 
do 

UPDATE 


in  TRACK  NUMBER 

L  <3° 

UPDATE  LO 
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package  bed?  MENU  MANAGER  is 
task  body  MENU  is 
begin 

accept  ACCES?  ME(M  ENU  TY  :  oun  MENU  type)  do 
—  insert  additions  1  b3dy  of  MENU 
end  ACCESS  ME; 
end  MENU; 
beqin 

— insert  additional  body  of  package  MENU  MANAGER 
end  MENU  MANAGER; 

packaae  body  ENGAGEMENT  PLAN  MANAGER  is 
rask  body  ENGAGEMENT  PLAU  is 
begin 

accept  ACCESS  EN  (TRACK  NUM  :  out  TRACK  NUMBER; 

PLAN  :  out  ‘ENGAGEMENT  PLAN; 

HOSTILE  ;  cut  HOS  TILETNAME  ; 

NATION  :  out  NATIONALITY; 

SHIP  ;  out  SHIP  CLASS; 

HEPS  :  out  HEAPONS; 

ECM  :  out  ECM  EQUIPMENT; 

METHOD  ;  out  ENGAGEMENT  METHOD)  do 
—  insert  additional  body  of  ACCESS  EN 
end  ACCESS  EN: 
end  ENGAGEMENT  ELAN; 

u  *  _  J  -  — 


begin 

—  insert  additional  body  of  package 

—  engagement  plan  manager 

end  ENGAGEMENT  PLAI  MANAGER; 
begin 

—  insert  additional  body  of  package  DATA  BASE  manager 
end  DATA  BASE  MANAGER:  ~ 
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